[Design] [Scooby] Scooby/Chandler Sharing, Interop

Sheila Mooney sheila at osafoundation.org
Fri Mar 3 15:53:15 PST 2006


I think this a good summary of the current situation. Mimi, Priscilla  
and I will start to tackle the 1.0 ecosystem strategy in the next  
several weeks so you should see lots of open dialog on this  
throughout 0.7.

On Mar 3, 2006, at 3:45 PM, Katie Capps Parlante wrote:

> Hi Bobby,
>
> These are good questions, and I know that Priscilla, Mimi and  
> Sheila are starting to tackle the product strategy for the whole  
> ecosystem (Scooby, Chandler and Cosmo).
>
> With that in mind, my personal thoughts about some of these  
> questions...
>
> When we talk about big picture goals, we perhaps have two  
> timeframes in mind: a grand vision (5 years out) and the 1.0  
> release for each project (12-18 months). It is good to have the  
> grand vision in mind because it inspires us, but the critical  
> decisions right now are about the 1.0 strategy. The 1.0 releases  
> are very important, because they are our shot at getting users. Its  
> very important for us to get users to sustain the project, both  
> financially and in terms of getting people to help us build the  
> grand vision.
>
> Bobby Rullo wrote:
>> Hi guys,
>> Now that we are about to release Scooby 0.1 I wanted to start the  
>> conversation on Scooby/Chandler Sharing and interoperability in  
>> general.
>> Scooby right now is a straight-up CalDAV client and knows nothing  
>> about the features that make Chandler special - like having events  
>> that can exist in more than one Calendar/Collection.
>> Some open questions:
>> * How much of Chandler's special* functionality do we want in  
>> Scooby?  And how should that affect interoperability?
>
> In the grand vision, both Chandler and Scooby would implement the  
> ideas that we've been excited about all of this time: from GTD to  
> tagging/labeling to being a shared data hub for all different kinds  
> of personal information.
>
> In the short term, we need to identify the use cases and the target  
> users for a 1.0 release. We've identified calendaring as the first  
> central application, but we haven't flushed it out to understand  
> who would be using it and how for 1.0. Priscilla, Mimi and Sheila  
> will be working on this (in an open way) and this should drive what  
> "special" functionality we include in Scooby.
>
>> * Do we want to extend CalDAV/WebDAV  to accomodate this stuff?
>
> Ultimately, that sounds like a good strategy. In the short term, is  
> that too ambitious for 1.0? I'm interested in hearing more about  
> the options from the folks who understand CalDAV/WebDAV better than  
> I do. ;)
>
>> * Is Scooby just a calendar client, or is it the online version of  
>> Chandler?
>
> I don't think Scooby needs to match Chandler feature for feature,  
> but that doesn't mean it has to be just a calendar client. We do  
> need a narrow enough focus that we can deliver a 1.0 in a  
> reasonable timeframe. Again, Priscilla, Mimi and Sheila are  
> starting the exercise that will answer this question.
>
>>    * In collections that have stuff other than icalendar  
>> resources, what should scooby be expected to do?
>
> Scooby could ignore the data if the feature set for a given release  
> doesn't need it. This decision should be driven by what features  
> Scooby wants to support for a given release.
>
>>    * How about plug-ins? Should Scooby have server-side plugins to  
>> match the client side plugins?
>
> I think the plugins make more sense for Chandler's 1.0 plan than  
> Scooby's 1.0 plan. A PIM enthusiast with just a little bit of  
> programming knowledge could customize the environment with some  
> Python code and share that parcel with other users, who would  
> download the parcel into their client. For Scooby, it requires  
> someone to run a different instance of Scooby on their server to  
> add their modifications.  Yes, Scooby should be written cleanly and  
> have a modular architecture so that people can run Scooby on their  
> own server with modifications, but that is a different bar than  
> allowing people to mod their personal copy of the client.
>
> My 2c is that Scooby server-side plugins to match the client side  
> plugins is *not* a requirement for 1.0, but am interested in  
> hearing from anyone who disagrees.
>
>> * What ARE these special features?
>> *special here means the functionality is not something than can be  
>> expressed with WebDAV or CalDAV semantics, like the events in  
>> multiple calendars example above.
>
> Off the top of my head:
> - bidirectional references between items
> - collections and how they are constructed (see ongoing thread  
> about collections)
> - stamping (one item has attributes from different "types" e.g.  
> mail and tasks)
> - events in multiple collections (calendars)
>
> I think you are correct that we need to make some decisions about  
> what the shared data model will support. The key piece here is  
> probably the "sharing format" which is going to need to be stable  
> across releases. Morgen is looking at this in more detail now.
>
> Cheers,
> Katie
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design



More information about the Design mailing list