[Chandler-dev] Just some questions...

[Jason LaChapelle]

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 <heikki at osafoundation.org> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20070221/57ba7713/attachment.html