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

[John Townsend]

On Jul 13, 2006, at 1:59 PM, Pieter Hartsook wrote:

> I realize there may be significant benefits for our project by using
> proprietary API's, but I wanted to raise the issue of the appearance
> of our support of open standards.
>
> If we decide to bypass the CalDAV API from Scooby to Cosmo in favor of
> proprietary integration, we should be aware that this could send a
> public message that OSAF, one of the primary implementers of CalDAV,
> felt that the standard was not appropriate for its own project
> internally .
>

If we are moving to a solution where Cosmo and Scooby are merged  
together into one web application that runs on the same server, it  
doesn't make sense to have Scooby issue HTTP-based CalDAV commands  
back to the same server to get data. Its more efficient in this case  
to go directly to the Cosmo APIs. If the Scooby application were  
hosted remotely (or could be hosted remotely), then the CalDAV APIs  
are the way to go about accessing Cosmo.

One thing we have talked about is that the ScoobyService API that  
exists in the Scooby codebase hides the details of how the data is  
gathered. Currently that API is implemented in terms of CalDAV4j. We  
would replace that implementation with a Cosmo API based  
implementation, but we might want to continue to maintain the  
CalDAV4j implementation in parallel in case Scooby every wants to run  
using standard CalDAV4j protocols. I am not sure if we are going to  
do this going forward, but its been sometihing that we have thought  
about.

CalDAV support within Cosmo remains unchanged by this merge. We will  
still continue to support CalDAV as a standard and will work to  
improve our CalDAV support over time.

As we have discussed recently, OSAF projects are moving towards an  
integrated ecosystem where Cosmo, Scooby, and Chandler work well  
together. Our first priority as a foundation is to the development of  
a viable ecosystem that can gain wide spread adoption. We still have  
a priority to promote open standards and interoperate with other  
servers/clients, but that is secondary to the primary goal of getting  
our ecosystem to a viable state for wide spread adoption.

To summarize, I think this merge still supports the goals of  
promoting open standards while providing more support for our  
ecosystem goals.

> If we go ahead with this approach we should have a reasonable position
> addressing this issue.
>
> Perhaps the position might be that CalDAV is important and supported
> as an interoperability protocol for exchanging and sharing event-based
> calendar information between solutions from different vendors, and
> that we will continue to incorporate and support that. But because the
> Chandler/Cosmo/Scooby solution is more broad, eventually encompassing
> more than just the calendar data addressed by CalDAV, we decided me
> needed a more proprietary solution for web access to our server on
> which we can store and retrieve calendar and as well as other kinds of
> information.

This is close. We're going to have to deal with this anyway when we  
roll out a new sharing format/protocol. Its likely that the sharing  
format's protocol will be DAV based, but it will be a new format that  
is not CalDAV.

>
> Whatever the reasoning, I think it has to go beyond just performance
> and time-to-market. And I think it will be essential to the eventual
> success of our project to continue our prominent support open
> standards and protocols that enable our products to interact easily
> with others'.
>

Agreed. And the Cosmo/Scooby teams feel just as strongly as you do  
about maintaining our commitment to open standards.

--> towns

> Pieter
>
> On 7/12/06, Brian Moseley <bcm at osafoundation.org> wrote:
>> On 7/12/06, John Townsend <towns at osafoundation.org> wrote:
>>
>> > 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.
>>
>> specifically, these are the items we've identified:
>>
>> * replace RequestPopulatingFilter with a jsp tag file that returns  
>> the
>> User for the current security context
>>
>> * add preferences to cosmo user model and repository schema. prefs  
>> are
>> generic key/value pairs. get constant names and namespaces from
>> o.o.s.ScoobyConstants.
>>
>> * throw away o.o.s.cosmo, httpclient, local, security, util from  
>> scooby
>>
>> * move o.o.s.model to o.o.c.rpc.model for the short term. longer  
>> term,
>> we want to merge that package into o.o.c.ui.bean, replacing existing
>> cosmo beans, converting between cosmo model and rpc client model,
>> using conversion strategy rather than wrapping for more efficient
>> transmission to rpc client
>>
>> * move o.o.s.rpc.service to o.o.c.rpc.service. re-implement
>> CosmoScoobyService to use cosmo internal service apis.
>>
>> * move o.o.s.spring to o.o.c.spring. consider making message  
>> resources
>> files static web resources rather than dynamically generated
>> javascript files
>>
>> * merge scooby webapp config into cosmo web.xml, mounting scooby at
>> /scooby for now, using path mapping rather than extension mapping for
>> scooby (eg /scooby/* not /*.page)
>>
>> * add applicationContext-security-scooby.xml that looks like
>> applicationContext-security-console.xml but with scooby specific uri
>> regexes and updating other bean definitions to acegi 1.0
>>
>> * remove cosmo login and logout procedures and have the app take you
>> directly to scooby when you login. add a link to the scooby layout
>> that will take you to the cosmo account and/or user mgmt pages
>>
>> * copy scooby's message resources files into cosmo but don't merge
>> with cosmo's since scooby's ones are used to dynamically deliver js
>> msg resources to the rpc client
>>
>> * throw away the rest of scooby's src/main/resources
>>
>> * integrate scooby's tests into cosmo as is, but get rid of spring
>> stuff, making the tests truly unit tests with mock objects, and throw
>> away rpc test
>> _______________________________________________
>> scooby-dev mailing list
>> scooby-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/scooby-dev
>>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev