2) chandler has no way to tell cosmo that chandler has subscribed to a remote calendar. the only thing chandler can do is copy the content of the remote calendar into its local repository and then sync a coppy of that content into cosmo. at that point the data in cosmo, the data in chandler, and the data in the origin calendar server are all copies of each other. it would be a lot nicer if chandler could just tell cosmo to subscribe itself to remote calendars, at least with regard to syncing. the down side is that if either cosmo or chandler has updated its subscription more recently than the other, the data you see in scooby and chandler could be slightly different.
I do think the idea of being able to see everything in Chandler in Scooby is important, although I see some potential problems with your model. With what you proposed Cosmo syncs to subscribed collections on its own time, as does Chandler. They are both maintaining copies of the subscribed data individually.
However, lots of what Chandler is about (I think!) is adding metadata to items in collections - stamping them, triaging them, tagging them. It might be tricky (not to say impossible!) to sync the metadata associated with these items since Cosmo and Chandler will be out of sync (with regards to subscribed collections) occasionally.
I also feel like it's vaguely wrong to have both Cosmo and Chandler having to sync to stuff. Maybe all syncing happens through Cosmo? It can't all happen through Chandler, cuz then Scooby has to wait for Chandler to update it.
Bobby _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
