[Chandler-dev] Just some questions...
heikki at osafoundation.org
Tue Feb 20 16:09:45 PST 2007
Jason LaChapelle wrote:
> First, this might be beating a dead horse so for that apologize. But
> while I was reading about your discussion about sharing information in
> Chandler all I could think about was XML and Remoting. How that could
> very possibly solve many of the problems you faced in terms of sharing.
> Assuming the book covered the most exhaustive areas of discussion about
> sharing I was quite surprised that Remoting was not brought up. I know
> Remoting is a fairly new topic (mostly related with .NET and might not
> work as well with Python) but is there a reason that Remoting was
> seemingly overlooked (according to the book, anyways)?
.NET Remoting is not cross platform or open source, which are
requirements for us.
Currently sharing happens via the Cosmo server. Basically one Chandler
uploads data to Cosmo, and other Chandler instances can download from
Cosmo. The protocol we use is CalDAV, which is a standard (which we have
also helped develop). CalDAV happens to use XML.
CalDAV being a standard has the nice benefit that Chandler and Cosmo can
interoperate with other CalDAV programs.
> My second "issue" is more of a suggestion then a question, really. On
> the issue of reoccurring events, why not just have one simple check box
> that states "Reoccurring?" and when the box is checked the event gets
> added into the repository for say 25 iterations. On the date that the 25
> iteration falls, pop up a simple dialog that asks something a long the
> lines of "Do you want to renew the reoccurring event X?" This way you
> can have infinite reoccurring events without filling up the repository
> with items until the year 2038 and beyond. This will also give the user
> a little control over what an "infinite" reoccurring event is.
Unfortunately that does not cover all the scenarios where recurrence
comes into play. For example, suppose I have weekly recurring meeting
with no end date. I then do a search that should display all of those
recurring events. I would be somewhat surprised if I saw only 25
instances of my event.
I am sure there are other cases like this which show why your strategy
might not be very user friendly.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20070220/deacd3f7/signature.pgp
More information about the chandler-dev