>From: "Alan Lovejoy" <squeak-dev.sourcery at forum-mail.net>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: "'The general-purpose Squeak developers 
>list'"<squeak-dev at lists.squeakfoundation.org>
>Subject: RE: [ANN] ICal occurrence API
>Date: Mon, 28 May 2007 14:06:57 -0700
>
>Yes.  And others have said the same thing.  One of the things I want to
>check is your interpretation of iCal versus mine.  And versus that of
>others.

My interpretation is actually from 
http://www.kanzaki.com/docs/ical/rrule.html.  I made a test case for every 
example they have.  This revealed (at least their interpretation of) how the 
various situations are interpreted.

The sole rule that I did not honor was that they seem to start the frequency 
from the boundary of dtstart (e.g. DTSTART:2007-05-23 would start at 
2007-01-01 for yearly frequency, 2007-05-01 for monthly, etc.) and simply 
drop all dates before dtstart in the set they return.

What I do is make the first period a "rest of" period (e.g. in the above 
example my periods would be {Period start: 2007-05-23 end: 2007-12-31. 
Period start: 2008-01-01 end: 2008-12-31...} for yearly).

There is only one test from that site that this difference shows up:  they 
pick the 3rd in the set from MO, WE, FR (as I recall) and the dtstart starts 
on the Monday, but there have already been a Wednesday and Friday in the 
month before it.  So the example picks the dtstart while I pick the Monday 
after.  I haven't tried to comply with this yet because I am thinking it 
maybe a conflict that will cause the other tests to return the wrong date.

>I'm sure you did.  So did I.  Chronos itself, and recurrence rules in
>particular, have proved to be far more complex and challenging than I had
>anticipated before I really got into them.  The date/time functional domain
>is not easy, not trivial, not simple, and cannot be adequately handled (let
>alone comprehensively handled) with only a handful of classes and methods.
>Collections and Streams are easy by comparison.

Yea, that system is really impressive.  You can probably get a P.H.D. in 
time now if you don't have one already. :)

>I am intrigued by your approach using LazyLists.  Since Chronos' recurrence
>rules are implemented as executable syntax trees, it should be possible to
>use them to emit ("compile") rules into your rule engine.
>
>--Alan

Yea, the LazyLists are just a simple way to delay computation while still 
appearing as a (more or less) normal Smalltalk collection class.  I wanted 
to handle the fact that any unbounded (i.e. no COUNT or UNTIL clause) set 
was infinite, while also handling the fact that the common use case is going 
to only want a small section of the dates (e.g. the most common will 
probably be calendar GUI's printing the current month).

The engine currently makes all it's decisions based on the instVars of it's 
frequency class, but I welcome any ideas you have for integration if you 
think you can use my work.

_________________________________________________________________
Make every IM count. Download Messenger and join the i’m Initiative now. 
It’s free. http://im.live.com/messenger/im/home/?source=TAGHM_MAY07