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
_______________________________________________
scooby-dev mailing list
scooby-dev lists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|