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

[Katie Capps Parlante]

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