[Cosmo-dev] Cosmo/Scooby Merge (Please read and comment)
John Townsend
towns at osafoundation.org
Wed Jul 12 20:12:01 PDT 2006
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
More information about the cosmo-dev
mailing list