Thank you for taking the time to answer my questions! :) I should of explained better my idea with Remoting, but I was trying to keep it short because I know you all are busy. I'm just guilty of the "I can build that better and do it quicker then the time it would take to integrate it" syndrome. I was thinking you could create a Remoting-like environment to work with. A way to share full objects instead of data about objects. The end product probably would not be worth the end product and, after finally using Cosmos and Chandler, I have to say that from this "noobs" point of view you made the best server decision you could with what you had to work with :)
Thanks again for taking the time to answer my question :) Keep up the great work with Chandler!! - Jay LaChapelle On 2/20/07, Heikki Toivonen <[EMAIL PROTECTED]> wrote:
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. -- Heikki Toivonen _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
