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

[Mikeal Rogers]

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  
to use.

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:
>
> - 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.

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.
>
> Thanks,
> --> John Townsend
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20060713/31562003/attachment.htm