-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Rob,
Great questions, and I''m glad you are getting into this stuff. Brief
(well, sort of) bit of background first... I originally started off
trying to use the vpim library before it had much of the maker stuff.
This basically required that you were very familiar with the iCalendar
specification because you had to put in raw strings for property values
etc. I was looking for a juicy ruby project to work on so I started in
on trying to implement some helpers which could simplify things a bit.
Long story short, I was looking at the problem in a different way than
Sam was (the author of vpim) and it just wasn''t going to work the way I
was hoping to make it. Sam had already sort of worked out how he wanted
to do things with the Maker type of scheme so he wasn''t really
interested in letting some new guy completely change the guts of his
library. Completely reasonable, but in the meantime I wanted to take a
shot at making it work how I was envisioning it could. So, I used some
of the vpim parsing code (Sam is credited in the source...) and started
in.
Rob Kaufman wrote:> Hi All,
> I need to create iCalendar objects and manipulate their elements
> (fields). I see there are two projects which provide iCalendar support
> in Ruby, and am not sure which to contribute to. I outlined my thoughts
> on the state of each projects and some (possibly worthless) comparison
> between the two at http://lightning-tree.net/ Some of the assertions
> made there may be false, but making them publicly seems to be the
> fastest way to find out =-) I really welcome any feed back I can get.
> For those who want the 1 minuet version, I''m basically asking two
> questions: Why two separate projects? Are either of them willing to
> accept some feature additions?
I''ll answer here first, and then try to get to some of the points you
mentioned in your blog. (Feel free to throw this email or portions of
it into a comment... I figured I''d reply here and let you decide.)
Why two projects? We were coming at this from different angles as
described above. (I also think its sort of odd to have vcard and
icalendar support in the same library. Although they are both derived
(at least logically) from the abnf & directory info world I think it
makes sense to have separate libraries...)
Since you seem to have scoped the code a bit I''ll give you and idea of
what I''ve been trying to do and I''ll respond to some of your
blog
comments. Looking at other icalendar libraries written in java, C &
python I was not envious of the people that wrote bazillions of methods
to get, set and validate every friggin property. Also, it seems like in
general many calendaring operations should be simple to handle without
having to be familiar with the specification. Hence the dynamic
property generators: ical_property and ical_multi_property (for single
and multiple instance properties...) They add a variety of methods
(basically attr_accessors using the specification name like "dtend" as
well as more natural versions like "end") that when paired with the
added to_ical methods for builtin classes can hopefully make it pretty
natural to edit icalendar data even if you aren''t familiar with the
specification.
Validation is yet to be tackled, but I have an idea that might help to
get mostly validated. Currently in the parser I list a bunch (might not
be complete yet, but it should list every property that isn''t a text
type) of properties that need to be specially parsed into ruby objects.
Rather than just doing this in the parser, it might make sense (as in
DRY) to just specify what types all the properties are somewhere else,
and then both validation and parsing methods can be setup to handle
general type safety. An interface could also be added which allowed
people to register new types/properties with associated parser &
validator methods to handle custom properties. More detailed validation
is probably going to have to be on a per property level, but eventually
that might have to happen for absolute correctness...
I definitely accept feature additions, suggestions, etc... Just
recently I''ve actually received a couple patches and bug fixes which
have all been integrated, and now that I''ve defended my masters thesis
(the reason for my development hiatus on this project...) I''m getting
back into the library. (My eventual goal is to develop a calendar
server which will use this library and maybe webrick with the DAV
additions... Its sitting dormant as gocal on rubyforge in the meantime.)
Oh yeah, adding error handling to the parser would be great. I''m
hoping
to get full support for property parameters working again first though.
Someone else said they might work on that a few weeks ago, but I
haven''t
heard more...
Hopefully that got at most of your comments. I''m going to be moving
later this week so things are going to be a little crazy, but feel free
to ping me about anything and I''ll try to get back to you.
Peace,
Jeff
> Thanks For Your Time,
> Rob Kaufman
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> icalendar-devel mailing list
> icalendar-devel@rubyforge.org
> http://rubyforge.org/mailman/listinfo/icalendar-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFDErnHABKrmewgEfIRAiB0AKCxPyYNymP402rLKnbskSwX/wi0eQCeNPlF
bjNF9bkW66akuSzH76A9LWA=WASn
-----END PGP SIGNATURE-----