From rgkaufman at gmail.com Mon Aug 29 00:54:22 2005 From: rgkaufman at gmail.com (Rob Kaufman) Date: Mon Aug 29 00:47:42 2005 Subject: [iCalendar-devel] Icalendar vs Vpim, where to contribute Message-ID: <17112e2f050828215435ea34a0@mail.gmail.com> 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? Thanks For Your Time, Rob Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/icalendar-devel/attachments/20050828/59777dc4/attachment.htm From rosejn at gmail.com Mon Aug 29 03:31:19 2005 From: rosejn at gmail.com (Jeff Rose) Date: Mon Aug 29 03:24:41 2005 Subject: [iCalendar-devel] Icalendar vs Vpim, where to contribute In-Reply-To: <17112e2f050828215435ea34a0@mail.gmail.com> References: <17112e2f050828215435ea34a0@mail.gmail.com> Message-ID: <4312B9C7.1050506@gmail.com> -----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----- From ericbardes at gmail.com Mon Aug 29 16:30:26 2005 From: ericbardes at gmail.com (Eric Bardes) Date: Mon Aug 29 16:23:44 2005 Subject: [iCalendar-devel] Re: Parsing Error In-Reply-To: <4312C3A5.9000102@gmail.com> References: <200508222107.j7ML7rlq024137@rubyforge.org> <4312C3A5.9000102@gmail.com> Message-ID: <953572d705082913307e6ed331@mail.gmail.com> Hello everyone, I made a local modification to my copy of Icalendar::Parser. I'm using Sunbird to maintain my calendar and it creates a timezone block that causes it to prematurely exit. The problem is that the BEGIN:VTIMEZONE works okay, but the BEGIN:DAYLIGHT and BEGIN:STANDARD do not, so the END:DAYLIGHT and END:STANDARD are inadvertently matched with BEGIN:VTIMEZONE and BEGIN:VCALENDAR, causing it to exit. My knee-jerk workaround, was to insert the else clause into the case statement that managed the "BEGIN" clause. when "VTIMEZONE" component.timezones << parse_component(Timezone.new) when "VALARM" component.alarms << parse_component(Alarm.new) else parse_component(component) end else # If its not a component then it should be a property I'll be the first to agree that this isn't what's right for icalendar. My work-around throws out timezone information, which limits it usefulness to everything but the local timezone and assumes all the input is in the local timezone of the current process. A better solution would include adding code that checks that each 'END' matches it's corresponding 'BEGIN' -- Cheers, Eric Bardes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/icalendar-devel/attachments/20050829/77261bbb/attachment.htm From brad at madriska.com Mon Aug 29 16:36:57 2005 From: brad at madriska.com (Brad Ediger) Date: Mon Aug 29 16:30:15 2005 Subject: [iCalendar-devel] Re: Parsing Error In-Reply-To: <953572d705082913307e6ed331@mail.gmail.com> References: <200508222107.j7ML7rlq024137@rubyforge.org> <4312C3A5.9000102@gmail.com> <953572d705082913307e6ed331@mail.gmail.com> Message-ID: <29FA6A12-4213-40D6-83E9-C13B70184532@madriska.com> Eric, I just patched that last week -- Jeff says it's in trunk. My copy ignores the timezone, too, so it isn't the best workaround, but it parses. I guess we need to look at a long-term solution, right? -- Brad Ediger Madriska Media Group www.madriska.com 866-334-4377 toll-free 815-301-3105 fax On Aug 29, 2005, at 3:30 PM, Eric Bardes wrote: > Hello everyone, I made a local modification to my copy of > Icalendar::Parser. I'm using Sunbird to maintain my calendar and > it creates a timezone block that causes it to prematurely exit. > The problem is that the BEGIN:VTIMEZONE works okay, but the > BEGIN:DAYLIGHT and BEGIN:STANDARD do not, so the END:DAYLIGHT and > END:STANDARD are inadvertently matched with BEGIN:VTIMEZONE and > BEGIN:VCALENDAR, causing it to exit. > > My knee-jerk workaround, was to insert the else clause into the > case statement that managed the "BEGIN" clause. > > when "VTIMEZONE" > component.timezones << parse_component(Timezone.new) > when "VALARM" > component.alarms << parse_component(Alarm.new) > else > parse_component(component) > end > else # If its not a component then it should be a property > > I'll be the first to agree that this isn't what's right for > icalendar. My work-around throws out timezone information, which > limits it usefulness to everything but the local timezone and > assumes all the input is in the local timezone of the current process. > > A better solution would include adding code that checks that each > 'END' matches it's corresponding 'BEGIN' > > -- > Cheers, > Eric Bardes > _______________________________________________ > icalendar-devel mailing list > icalendar-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/icalendar-devel > From rosejn at gmail.com Wed Aug 31 16:04:34 2005 From: rosejn at gmail.com (Jeff Rose) Date: Wed Aug 31 15:57:55 2005 Subject: [iCalendar-devel] Re: Parsing Error In-Reply-To: <29FA6A12-4213-40D6-83E9-C13B70184532@madriska.com> References: <200508222107.j7ML7rlq024137@rubyforge.org> <4312C3A5.9000102@gmail.com> <953572d705082913307e6ed331@mail.gmail.com> <29FA6A12-4213-40D6-83E9-C13B70184532@madriska.com> Message-ID: <43160D52.3050506@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yeah, I've put in this fix for now, but in general this is something that will have to be worked into the parser. I'm in the process of moving to Switzerland from Colorado so things are a bit chaotic, but property parameters and correct support of nested components are at the top of the list. (Someone was talking about working on property parameters.... any progress on that? I don't remember who it was.) I think I've just about got my textdrive account setup for public access to the subversion repository. Once its ready I'll post to the list so you guys can work of trunk directly. I'm also working on a collaboa installation so people can post tickets for feature requests, bugs etc... If a few people could post sample calendars from whichever programs they are using to the list that would be helpful for now. It would be great to put together a suite of test calendars from various apps which can be used for both unit testing as well as showing functionality with the sample applications. - - Jeff Brad Ediger wrote: > Eric, > I just patched that last week -- Jeff says it's in trunk. My copy > ignores the timezone, too, so it isn't the best workaround, but it > parses. I guess we need to look at a long-term solution, right? > > -- > Brad Ediger > Madriska Media Group > www.madriska.com > 866-334-4377 toll-free > 815-301-3105 fax > > > On Aug 29, 2005, at 3:30 PM, Eric Bardes wrote: > >> Hello everyone, I made a local modification to my copy of >> Icalendar::Parser. I'm using Sunbird to maintain my calendar and it >> creates a timezone block that causes it to prematurely exit. The >> problem is that the BEGIN:VTIMEZONE works okay, but the >> BEGIN:DAYLIGHT and BEGIN:STANDARD do not, so the END:DAYLIGHT and >> END:STANDARD are inadvertently matched with BEGIN:VTIMEZONE and >> BEGIN:VCALENDAR, causing it to exit. >> >> My knee-jerk workaround, was to insert the else clause into the case >> statement that managed the "BEGIN" clause. >> >> when "VTIMEZONE" >> component.timezones << parse_component(Timezone.new) >> when "VALARM" >> component.alarms << parse_component(Alarm.new) >> else >> parse_component(component) >> end >> else # If its not a component then it should be a property >> >> I'll be the first to agree that this isn't what's right for >> icalendar. My work-around throws out timezone information, which >> limits it usefulness to everything but the local timezone and assumes >> all the input is in the local timezone of the current process. >> >> A better solution would include adding code that checks that each >> 'END' matches it's corresponding 'BEGIN' >> >> -- >> Cheers, >> Eric Bardes >> _______________________________________________ >> icalendar-devel mailing list >> icalendar-devel@rubyforge.org >> http://rubyforge.org/mailman/listinfo/icalendar-devel >> > > _______________________________________________ > 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) iD8DBQFDFg1SABKrmewgEfIRAnTnAKDcbB1Ew5JV8i5s2zF25XWFq5F6mgCeIO5N 3t7U8P+zYwhAGQ0pzgdj1mY= =P12M -----END PGP SIGNATURE-----