[Cosmo-dev] Cosmo/Scooby Merge (Please read and comment)
mikeal at osafoundation.org
Thu Jul 13 13:13:42 PDT 2006
Here are my concerns.
The real reason we are thinking of this is to prioritize "eco-system
work" ahead of other work. I don't believe this is a superior
architecture, for reasons I will describe later. I'd like to know
what people think the real development impact of this will be, by
this I mean in terms of days in a release cycle how much faster do we
really think this will make improving the features we have
prioritized as "eco-system work".
The "benefit" of scooby directly accessing the repository is obvious,
scooby would no longer have to wait for cosmo to expose a feature and
information about a resource via a public interface. The downside is
that we've removed our incentive to build those interfaces, which
means we have effectively said "we won't be supporting people
interoperating with our eco-system that aren't here at OSAF until
after beta, if ever". We would really be ditching support of open
interfaces to the features we build beyond what we've already written.
Notice that I've used the term "effectively", nobody is saying
outright that we are pushing off third party client interop
indefinitely, but what everyone is saying is that scooby will no
longer be the same kind of cosmo consumer as another client would be
while we're simultaneously saying that we are prioritizing "eco-
system" work ahead of third party client interop work. What this
means is that we're ditching it, possibly forever since nobody knows
the extent to which we may later decide to couple the products, many
features may be built into the repository that only scooby knows how
Right now our process goes something like "scooby needs a feature,
what can cosmo do to support this?". This drives the success of cosmo
because it has these kinds of demands for a public interface to
features it builds. This adds value to the products at OSAF and to
our eco-system. If we're going to be a successful open source project
we should have an open architecture that will support visions outside
of the short term goals of OSAF.
As a hypothetical, what valuable assets would we presumably not have
at OSAF if scooby were coupled to cosmo from the start. Off the top
of my head I can see no reason we would have a functional reference
java client for CalDAV (CalDAV4j, or any CalDAV reports other than
Freebusy which was requested by Chandler.
More comments are in line below....
On Jul 12, 2006, at 8:12 PM, John Townsend wrote:
> 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:
> 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.
This does not require coupling the products unless we are giving up
on exposing all the data in Cosmo via public interfaces. Is cosmo
really a "sharing server" if you have to have direct access to the
repository to view and manipulate the data?
> - 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)
I'm really not convinced that this is a major improvement. Our main
performance issue now has to do with the repository, not with
serializing the data in an open format and sending it over the local
network to scooby. If scooby is connected directly to the repository
today we would still have the same speed issues and you can't tell me
that with nearly every product at google being exposed over a public
interface that there isn't a way to solve any future performance
issues we might have with doing it this way.
> - Better support for the ecosystem. This merge makes solving things
> like the Scooby sharing URL problem easier to resolve.
But it also means that we will only be solving problems in a way that
relates to us and nobody else. We're all smart enough to come up with
innovative OPEN solutions to these problems that, even if they don't
in the short term, can translate into solving those problems outside
of clients built at OSAF.
> - 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.
This does not require tight coupling of the products. We could easily
have a "common" directory that contains all the relevant cross-
product code and is built into the osaf-server-bundle once.
> 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)
Sure, next month we'll be able to remove scooby from cosmo, but how
long until the products are so tightly coupled that you can't remove
them. From what I can see there isn't a really big problem we are
trying to solve with this merger, it's just a move to make some of
our development easier, if this is the case then ending support for
removing scooby could easily be justified down the line.
> - 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.
We have some cosmo dependencies, like auth. But if a third party
developer cared enough about it they could contribute code that
removed our cosmo dependencies or allows for you to limit the feature
set in scooby to features that relate to servers that implement a
subset of the open interfaces that scooby uses in cosmo. This is
impossible if scooby accesses the repository directly.
> - 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.
CalDAV4j is a great asset to OSAF and will most likely be used by
others outside of OSAF and I believe we will get some great
contributions and free testing because of it. The more we extend
cosmo, if we are exposing the features via a public interface, the
more the scooby team can extend our library of java clients that add
value to OSAF.
> 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.
> --> John Townsend
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cosmo-dev