[Scooby-dev] Cosmo/Scooby Merge (Please read and comment)

[John Townsend]

Hello Everyone,

Based on the conversations that have occured on the mailing lists the  
past few weeks, it has been suggested that merging Cosmo and Scooby  
into one project is something that should be considered. I would like  
to talk about this idea on the list and this email is intended to  
kick start that conversation and see what the community at large  
thinks about this idea.

The basic idea is to merge the Scooby Web Calendaring Application  
into Cosmo. At a very high level, this would mean:

- Moving the Scooby webapp code (the JSPs, JavaScript, etc.) into the  
cosmo web application.
- Move the Cosmo web app (repository browser, admin console) to a  
Spring-based codebase.
- Integrate the URL structures of the various webapps so that they  
made sense.
- Move the Scooby Java code into the Cosmo java source code tree.
- Make sure that the acegi security implementations are merged.
- Merge the Cosmo and Sooby mailing lists.
- Integrate the Program Management and Product Management functions  
more closely.

The pros of this move might be:
- One integrated project where Scooby's webapp would become the user  
view of the Cosmo server.
- Possible performance improvements for Scooby (Scooby currently uses  
CalDAV to talk to Cosmo, in an integrated solution, Scooby could be  
refactored to use Cosmo APIs directly)
- Better support for the ecosystem. This merge makes solving things  
like the Scooby sharing URL problem easier to resolve.
- Common code between the Scooby and Cosmo web facing applications  
allows for better reuse without copying the code between projects. We  
are roll out things like Dojo and they are usable in entire project  
immediately.

Cons might be:
- Clients who don't want Scooby would get it anyway (We currently  
deliver both projects as a server bundled release, so clients are  
already use to this. We would want to find a way to allow clients to  
easily configure a scooby-less Cosmo server for non-ecosystem use)
- Scooby has been designed to be a Web Calendar that uses CalDAV as  
its data transport mechanism. This serves two purposes: 1. It acts as  
a testbed for Cosmo's CalDAV support and 2. In theory, Scooby could  
be a CalDAV client for another CalDAV server. Turns out that we  
already have Cosmo dependencies that eliminate #2.
- Less of a need for CalDAV4j. We would still need it for  
interoperability within Scooby (subscribing to external calendars),  
but Scooby would be much less dependent on the library than it is  
today. That could lead to some "bit rot" or certainly less of a focus  
on this component in the future.

This is probably just scratching the surface on this issue but it  
should cover the broad strokes. We have had a couple of brief  
discussions on this issue internally in the office, but we have not  
made any decisions as of yet. Bobby Rullo and Brian Moseley have been  
doing some work to explore what it would take to merge the two  
projects into one and will be posting their thoughts to the lists.

Any and all comments are welcome. Please fire away. But please do it  
soon. I would like to issue a Last Call on this issue and make a  
decision on the list in the next few days.

Thanks,
--> John Townsend