From: "Alan Lovejoy" squeak-dev.sourcery@forum-mail.net Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'The general-purpose Squeak developers list'"squeak-dev@lists.squeakfoundation.org Subject: RE: [ANN] ICal occurrence API Date: Mon, 28 May 2007 12:54:48 -0700
I fully intend to have a look at your code--after I've completed my implementation. However, I don't plan on implementing a parser for iCal--the only goal is to be able to specify/represent (and fully and correctly implement) the iCal rule model.
I didn't either. The iCalendar package made by Philippe does all that, it just didn't do anything with the recurrence rules once made.
Actually, the Chronos recurrence rule model goes beyond what can be specified using the iCal rule model/notation. Using an algebra enables support for logical negation and disjunction, among other things (consider what Chalten does with its TimeLineFilter, for example.)
That sounds cool. I went for the Recurrence rule standard which is ugly, ambiguous and, though my test coverage didn't point anything out, I think even self-contradicting.
I don't know anything about recurrence rule algebra but it sounds good. :)
I'm also working on full support for business date arithmetic. I intend to meet or exceed the capabilities offered by jFin (http://jfin.org/date_adjustment) or ObjectLab (http://objectlabkit.sourceforge.net/), and to use the data provided by FinancialCalendar.com (http://financialcalendar.com/).
Very cool.
As for "thunder stealing," that goes with the territory when two or more projects are in the same functional domain. My goal is to implement the world's best date/time library in any language--and I've been working hard at it since October 2004. I feel I've already achieved parity with anything else out there. Now it's time to go to the next level.
I wasn't mad or anything. Just joking because of the timing of it. :) But yes, now that you point it out, it would make more sense that the recurrence calculation code be with a time library, whether you use anything of mine or not. I learned a lot in the doing.
But, since my main motivation for making Chronos the best date/time library in the world is to help promote Smalltalk, I actually welcome any and all contributions by others to that goal. And based on the description, your iCal engine certainly seems to be a worthy contribution.
Thanks. I don't know how much of my stuff will be usable for you. I got the approach from Haskell. Basically the strategy is that the frequency creates an infinite list of "periods" which are the same thing as a TimeSpan but with a different interface. All constraints (e.g. BYDAY) are applied to the period stream they get, and they generate the next period stream from it. Once you get through all the constraints you should have the dates.
Working together, we can leave Smalltalk's competition in the dust. And inspire those working on Smalltalk projects in domains other than dates/times to do the same.
Go Smalltalk!
--Alan
That is what I want as well. :)
_________________________________________________________________ PC Magazines 2007 editors choice for best Web mailaward-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migr...
<JJ (Jason)>I went for the Recurrence rule standard which is ugly, ambiguous and, though my test coverage didn't point anything out, I think even self-contradicting.</JJ (Jason)>
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.
One of the issues I'm dealing with is to ensure that the Chronos rule model can represent any of the possible interpretations of an iCal ruleset, so that the ambiguity issue will be the sole responsibility of the iCal parser.
And of course, I have to ensure that recurrence rules using non-Gregorian calendars also work correctly--something iCal currently doesn't address.
<JJ (Jason)>I learned a lot in the doing.</JJ (Jason)>
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.
<JJ (Jason)>I don't know how much of my stuff will be usable for you.</JJ (Jason)>
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
Jason,
I spent the the last hour rooting around in the latest version of the iCalendar package from SqueakSource. I see lots of code for parsing and representing iCal recurrence rules, but can't find any code that actually attempts to generate the set of occurrences specified by the rules.
Am I missing something?
--Alan
squeak-dev@lists.squeakfoundation.org
-
Alan L. Lovejoy -
Alan Lovejoy -
J J