From rgkaufman at gmail.com Mon Apr 2 13:39:20 2007 From: rgkaufman at gmail.com (Rob Kaufman) Date: Mon, 2 Apr 2007 10:39:20 -0700 Subject: [iCalendar-devel] Handling start and duration but no end for Events In-Reply-To: <12FD59BA-3EE2-4783-BE31-EFC0E2929349@opensourceconnections.com> References: <12FD59BA-3EE2-4783-BE31-EFC0E2929349@opensourceconnections.com> Message-ID: <17112e2f0704021039k1aa2f5b1ra275a2213a52642a@mail.gmail.com> According to the icalendar spec, you must specify EITHER duration or end, so it would make a lot of since for setting duration to implicitly set end in the parser and vis-versa. You are correct that the parser does not currently handle the case where there is no end. Rob Kaufman On 3/30/07, Eric Pugh wrote: > Hi all, > > I've got an event that looks like: > > BEGIN:VEVENT > DTSTART;TZID=US/Eastern:20070402T140000 > SUMMARY:Call Robert > UID:A11B2175-8082-4839-B253-74D1A6CACBA9 > SEQUENCE:4 > DTSTAMP:20070329T150439Z > DESCRIPTION:Call to find out about bringing in Window guys...... \n\n4 > 34-962-7950 > DURATION:PT1H > BEGIN:VALARM > ACTION:AUDIO > TRIGGER:-PT15M > X-WR-ALARMUID:76466515-A5C5-41C1-AECF-BF8C8BF972E0 > X-ICF-AUTOALARM:TRUE > ATTACH;VALUE=URI:Basso > END:VALARM > END:VEVENT > > It has a start time, but no end time. However, it does have a > duration of PT1H. My app is failing cause I have no end time. > Should the iCalendar parser handle the fact that the end time isn't > definined, and supply it based on the start time + duration? Or is > this the responsibility of the user of the parser??? > > I'm asking more from an understanding point of view? Seeing if I > should patch icalendar parser or deal with it in my code. > > Eric > > > ------------------------------------------------------- > Principal > OpenSource Connections > Site: http://www.opensourceconnections.com > Blog: http://blog.opensourceconnections.com > Cell: 1-434-466-1467 > > > > > _______________________________________________ > icalendar-devel mailing list > icalendar-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/icalendar-devel > From epugh at opensourceconnections.com Mon Apr 2 14:53:30 2007 From: epugh at opensourceconnections.com (Eric Pugh) Date: Mon, 2 Apr 2007 14:53:30 -0400 Subject: [iCalendar-devel] Handling start and duration but no end for Events In-Reply-To: <17112e2f0704021039k1aa2f5b1ra275a2213a52642a@mail.gmail.com> References: <12FD59BA-3EE2-4783-BE31-EFC0E2929349@opensourceconnections.com> <17112e2f0704021039k1aa2f5b1ra275a2213a52642a@mail.gmail.com> Message-ID: <8825484E-527E-47F7-94BB-256CA7405744@opensourceconnections.com> I've been going over this in my mind... If you assume that the iCalendar tool is purely a "parser" then maybe it works the way you would expect, returning nil for the end, instead of figuring it out. Because that is what the "parsed" data says. However, if you think there should be some handholding from the parser, or that you have two layers, the low level data and higher level user objects, then the higher level user objects should handle this then! I think I may just add a layer to my app that adds those sorts of higher level "convenience" methods. argh... Eric Pugh On Apr 2, 2007, at 1:39 PM, Rob Kaufman wrote: > According to the icalendar spec, you must specify EITHER duration or > end, so it would make a lot of since for setting duration to > implicitly set end in the parser and vis-versa. You are correct that > the parser does not currently handle the case where there is no end. > > Rob Kaufman > > On 3/30/07, Eric Pugh wrote: >> Hi all, >> >> I've got an event that looks like: >> >> BEGIN:VEVENT >> DTSTART;TZID=US/Eastern:20070402T140000 >> SUMMARY:Call Robert >> UID:A11B2175-8082-4839-B253-74D1A6CACBA9 >> SEQUENCE:4 >> DTSTAMP:20070329T150439Z >> DESCRIPTION:Call to find out about bringing in Window guys...... >> \n\n4 >> 34-962-7950 >> DURATION:PT1H >> BEGIN:VALARM >> ACTION:AUDIO >> TRIGGER:-PT15M >> X-WR-ALARMUID:76466515-A5C5-41C1-AECF-BF8C8BF972E0 >> X-ICF-AUTOALARM:TRUE >> ATTACH;VALUE=URI:Basso >> END:VALARM >> END:VEVENT >> >> It has a start time, but no end time. However, it does have a >> duration of PT1H. My app is failing cause I have no end time. >> Should the iCalendar parser handle the fact that the end time isn't >> definined, and supply it based on the start time + duration? Or is >> this the responsibility of the user of the parser??? >> >> I'm asking more from an understanding point of view? Seeing if I >> should patch icalendar parser or deal with it in my code. >> >> Eric >> >> >> ------------------------------------------------------- >> Principal >> OpenSource Connections >> Site: http://www.opensourceconnections.com >> Blog: http://blog.opensourceconnections.com >> Cell: 1-434-466-1467 >> >> >> >> >> _______________________________________________ >> icalendar-devel mailing list >> icalendar-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/icalendar-devel >> > _______________________________________________ > icalendar-devel mailing list > icalendar-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/icalendar-devel ------------------------------------------------------- Principal OpenSource Connections Site: http://www.opensourceconnections.com Blog: http://blog.opensourceconnections.com Cell: 1-434-466-1467 From larry.karnowski at gmail.com Mon Apr 2 15:10:42 2007 From: larry.karnowski at gmail.com (Larry Karnowski) Date: Mon, 2 Apr 2007 15:10:42 -0400 Subject: [iCalendar-devel] Handling start and duration but no end for Events In-Reply-To: <8825484E-527E-47F7-94BB-256CA7405744@opensourceconnections.com> References: <12FD59BA-3EE2-4783-BE31-EFC0E2929349@opensourceconnections.com> <17112e2f0704021039k1aa2f5b1ra275a2213a52642a@mail.gmail.com> <8825484E-527E-47F7-94BB-256CA7405744@opensourceconnections.com> Message-ID: <2b27183e0704021210l497247b8l54b8e3dd19340ba1@mail.gmail.com> Eric, Could you incorporate both into the parser with a "lenient" flag? I can see both uses, but I would think the "happy path" of leniency would suit most users better. Larry On 4/2/07, Eric Pugh wrote: > I've been going over this in my mind... If you assume that the > iCalendar tool is purely a "parser" then maybe it works the way you > would expect, returning nil for the end, instead of figuring it out. > Because that is what the "parsed" data says. However, if you think > there should be some handholding from the parser, or that you have > two layers, the low level data and higher level user objects, then > the higher level user objects should handle this then! > > I think I may just add a layer to my app that adds those sorts of > higher level "convenience" methods. argh... > > Eric Pugh > > > > > On Apr 2, 2007, at 1:39 PM, Rob Kaufman wrote: > > > According to the icalendar spec, you must specify EITHER duration or > > end, so it would make a lot of since for setting duration to > > implicitly set end in the parser and vis-versa. You are correct that > > the parser does not currently handle the case where there is no end. > > > > Rob Kaufman > > > > On 3/30/07, Eric Pugh wrote: > >> Hi all, > >> > >> I've got an event that looks like: > >> > >> BEGIN:VEVENT > >> DTSTART;TZID=US/Eastern:20070402T140000 > >> SUMMARY:Call Robert > >> UID:A11B2175-8082-4839-B253-74D1A6CACBA9 > >> SEQUENCE:4 > >> DTSTAMP:20070329T150439Z > >> DESCRIPTION:Call to find out about bringing in Window guys...... > >> \n\n4 > >> 34-962-7950 > >> DURATION:PT1H > >> BEGIN:VALARM > >> ACTION:AUDIO > >> TRIGGER:-PT15M > >> X-WR-ALARMUID:76466515-A5C5-41C1-AECF-BF8C8BF972E0 > >> X-ICF-AUTOALARM:TRUE > >> ATTACH;VALUE=URI:Basso > >> END:VALARM > >> END:VEVENT > >> > >> It has a start time, but no end time. However, it does have a > >> duration of PT1H. My app is failing cause I have no end time. > >> Should the iCalendar parser handle the fact that the end time isn't > >> definined, and supply it based on the start time + duration? Or is > >> this the responsibility of the user of the parser??? > >> > >> I'm asking more from an understanding point of view? Seeing if I > >> should patch icalendar parser or deal with it in my code. > >> > >> Eric > >> > >> > >> ------------------------------------------------------- > >> Principal > >> OpenSource Connections > >> Site: http://www.opensourceconnections.com > >> Blog: http://blog.opensourceconnections.com > >> Cell: 1-434-466-1467 > >> > >> > >> > >> > >> _______________________________________________ > >> icalendar-devel mailing list > >> icalendar-devel at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/icalendar-devel > >> > > _______________________________________________ > > icalendar-devel mailing list > > icalendar-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/icalendar-devel > > ------------------------------------------------------- > Principal > OpenSource Connections > Site: http://www.opensourceconnections.com > Blog: http://blog.opensourceconnections.com > Cell: 1-434-466-1467 > > > > > _______________________________________________ > icalendar-devel mailing list > icalendar-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/icalendar-devel > From epugh at opensourceconnections.com Tue Apr 3 15:17:08 2007 From: epugh at opensourceconnections.com (Eric Pugh) Date: Tue, 3 Apr 2007 15:17:08 -0400 Subject: [iCalendar-devel] Handling start and duration but no end for Events In-Reply-To: <2b27183e0704021210l497247b8l54b8e3dd19340ba1@mail.gmail.com> References: <12FD59BA-3EE2-4783-BE31-EFC0E2929349@opensourceconnections.com> <17112e2f0704021039k1aa2f5b1ra275a2213a52642a@mail.gmail.com> <8825484E-527E-47F7-94BB-256CA7405744@opensourceconnections.com> <2b27183e0704021210l497247b8l54b8e3dd19340ba1@mail.gmail.com> Message-ID: <1F120827-B344-4443-AE54-D2C422D5DFB9@opensourceconnections.com> I don't have commit privileges on the underlying icalendar project, so right now I am trying to not change anything there, I'll probably be playing around with layering on other stuff... If you are interested, monitor novo.rubyforge.org, and look at "sync_gcal.rb" script.. It's all a bit icky, unorganized, but I'm learning a lot out of this project. I do like the "lenient" idea! I discoved in "parser.rb" that the developer didn't know how to parse duration which is in an odd standard formation. However, turns out the the Vpim::Calendar project can handle it! gem install vpim and run this unit test: # Test that Vpim library will do the duration conversion we need! def test_vpim_library result = Vpim::Icalendar.decode_duration('PT1H') assert_equal 3600, result result = Vpim::Icalendar.decode_duration('PT2H10M') assert_equal 7800, result end I'll try and use this, and then layer in populating the end method.... ERic On Apr 2, 2007, at 3:10 PM, Larry Karnowski wrote: > Eric, > Could you incorporate both into the parser with a "lenient" flag? I > can see both uses, but I would think the "happy path" of leniency > would suit most users better. > > Larry > > On 4/2/07, Eric Pugh wrote: >> I've been going over this in my mind... If you assume that the >> iCalendar tool is purely a "parser" then maybe it works the way you >> would expect, returning nil for the end, instead of figuring it out. >> Because that is what the "parsed" data says. However, if you think >> there should be some handholding from the parser, or that you have >> two layers, the low level data and higher level user objects, then >> the higher level user objects should handle this then! >> >> I think I may just add a layer to my app that adds those sorts of >> higher level "convenience" methods. argh... >> >> Eric Pugh >> >> >> >> >> On Apr 2, 2007, at 1:39 PM, Rob Kaufman wrote: >> >>> According to the icalendar spec, you must specify EITHER duration or >>> end, so it would make a lot of since for setting duration to >>> implicitly set end in the parser and vis-versa. You are correct >>> that >>> the parser does not currently handle the case where there is no end. >>> >>> Rob Kaufman >>> >>> On 3/30/07, Eric Pugh wrote: >>>> Hi all, >>>> >>>> I've got an event that looks like: >>>> >>>> BEGIN:VEVENT >>>> DTSTART;TZID=US/Eastern:20070402T140000 >>>> SUMMARY:Call Robert >>>> UID:A11B2175-8082-4839-B253-74D1A6CACBA9 >>>> SEQUENCE:4 >>>> DTSTAMP:20070329T150439Z >>>> DESCRIPTION:Call to find out about bringing in Window guys...... >>>> \n\n4 >>>> 34-962-7950 >>>> DURATION:PT1H >>>> BEGIN:VALARM >>>> ACTION:AUDIO >>>> TRIGGER:-PT15M >>>> X-WR-ALARMUID:76466515-A5C5-41C1-AECF-BF8C8BF972E0 >>>> X-ICF-AUTOALARM:TRUE >>>> ATTACH;VALUE=URI:Basso >>>> END:VALARM >>>> END:VEVENT >>>> >>>> It has a start time, but no end time. However, it does have a >>>> duration of PT1H. My app is failing cause I have no end time. >>>> Should the iCalendar parser handle the fact that the end time isn't >>>> definined, and supply it based on the start time + duration? Or is >>>> this the responsibility of the user of the parser??? >>>> >>>> I'm asking more from an understanding point of view? Seeing if I >>>> should patch icalendar parser or deal with it in my code. >>>> >>>> Eric >>>> >>>> >>>> ------------------------------------------------------- >>>> Principal >>>> OpenSource Connections >>>> Site: http://www.opensourceconnections.com >>>> Blog: http://blog.opensourceconnections.com >>>> Cell: 1-434-466-1467 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> icalendar-devel mailing list >>>> icalendar-devel at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/icalendar-devel >>>> >>> _______________________________________________ >>> icalendar-devel mailing list >>> icalendar-devel at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/icalendar-devel >> >> ------------------------------------------------------- >> Principal >> OpenSource Connections >> Site: http://www.opensourceconnections.com >> Blog: http://blog.opensourceconnections.com >> Cell: 1-434-466-1467 >> >> >> >> >> _______________________________________________ >> icalendar-devel mailing list >> icalendar-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/icalendar-devel >> > _______________________________________________ > icalendar-devel mailing list > icalendar-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/icalendar-devel ------------------------------------------------------- Principal OpenSource Connections Site: http://www.opensourceconnections.com Blog: http://blog.opensourceconnections.com Cell: 1-434-466-1467 From larry.karnowski at gmail.com Tue Apr 3 15:57:20 2007 From: larry.karnowski at gmail.com (Larry Karnowski) Date: Tue, 3 Apr 2007 15:57:20 -0400 Subject: [iCalendar-devel] Recurrence Rules and Runt Message-ID: <2b27183e0704031257hf6e9306iabb339f9301d7d82@mail.gmail.com> All, I've been the "guy in a room" for too long. I need to come clean on what I have (and haven't) been doing with the recurrence rules. I started by trying to brute force them, but I soon realized that wasn't working. They're pretty sophisticated. Then Nathaniel Talbott pointed me at Runt, and that was a huge help. I then tried to brute force Runt into iCalendar, but now I'm seeing that's not working either. Runt is about 60-70% of where we need it to be. So, I've taken a step back. Currently I'm implementing all the examples from section 4.8.5.4 of the RFC2445 as unit tests for Runt. I want to get Runt handling all of these examples first, and from that create a generalized algorithm for iCalendar that just plugs these Runt temporal expressions together. The major pieces Runt lacks are "weekly" timeframe support and a few "yearly" features. Shouldn't be too hard to hack in, given a little time. I'm attaching the little bit of code that I'm actually keeping, some patches to the SVN unstable version of Runt. (Tentatively this is called Runt 0.4.0.) I'm trying to get a hold of Matthew Lipper, the maintainer of Runt, but I must be stuck in his spam folder. Does anyone know him? So my plan is: 1) Get all required functionality into Runt. 2) Get Matthew Lipper to accept those patches and release Runt 0.4.0. 3) Implement the recurrence rules in terms of Runt for iCalendar. 4) Take over the world, Pinky. Sound good? Please look over these and point out any glaring errors. I'm still learning Ruby and would love some tips! Thanks, Larry -------------- next part -------------- A non-text attachment was scrubbed... Name: icalendartest.rb Type: application/octet-stream Size: 22913 bytes Desc: not available Url : http://rubyforge.org/pipermail/icalendar-devel/attachments/20070403/41c85c40/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: temporalexpression.patch Type: application/octet-stream Size: 1197 bytes Desc: not available Url : http://rubyforge.org/pipermail/icalendar-devel/attachments/20070403/41c85c40/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: temporalexpressiontest.patch Type: application/octet-stream Size: 3492 bytes Desc: not available Url : http://rubyforge.org/pipermail/icalendar-devel/attachments/20070403/41c85c40/attachment-0005.obj From jeff at rosejn.net Tue Apr 3 19:22:19 2007 From: jeff at rosejn.net (Jeff Rose) Date: Tue, 03 Apr 2007 16:22:19 -0700 Subject: [iCalendar-devel] Handling start and duration but no end for Events In-Reply-To: <1F120827-B344-4443-AE54-D2C422D5DFB9@opensourceconnections.com> References: <12FD59BA-3EE2-4783-BE31-EFC0E2929349@opensourceconnections.com> <17112e2f0704021039k1aa2f5b1ra275a2213a52642a@mail.gmail.com> <8825484E-527E-47F7-94BB-256CA7405744@opensourceconnections.com> <2b27183e0704021210l497247b8l54b8e3dd19340ba1@mail.gmail.com> <1F120827-B344-4443-AE54-D2C422D5DFB9@opensourceconnections.com> Message-ID: <4612E1AB.8040002@rosejn.net> Eric Pugh wrote: > I don't have commit privileges on the underlying icalendar project, > so right now I am trying to not change anything there, I'll probably > be playing around with layering on other stuff... Please feel free to propose changes to the library and/or submit patches to the list. I'm using git for the repository, so I can give out the URL so people can grab the latest source and patch locally if you are interested in doing that. > I discoved in "parser.rb" that the developer didn't know how to parse > duration which is in an odd standard formation. What do you mean odd formation? If you can post an example of a calendar that breaks the parser I'd like to fix any problems. >> On 4/2/07, Eric Pugh wrote: >>> I've been going over this in my mind... If you assume that the >>> iCalendar tool is purely a "parser" then maybe it works the way you >>> would expect, returning nil for the end, instead of figuring it out. >>> Because that is what the "parsed" data says. However, if you think >>> there should be some handholding from the parser, or that you have >>> two layers, the low level data and higher level user objects, then >>> the higher level user objects should handle this then! You are very correct, but my hope is that we can add helpful bits and pieces like this over time to make it easier to use. It ends up being mostly policy decisions about how things should work, but we should be able to come to consensus on what is reasonable for most of these cases. >>>>> It has a start time, but no end time. However, it does have a >>>>> duration of PT1H. My app is failing cause I have no end time. >>>>> Should the iCalendar parser handle the fact that the end time isn't >>>>> definined, and supply it based on the start time + duration? Or is >>>>> this the responsibility of the user of the parser??? In this type of situation, what do you guys think about having the library compute whichever property is missing (dtend or duration), and then when writing out just always write the end time? If it seemed necessary maybe there could be an option for writing duration instead... -Jeff