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

[Pieter Hartsook]

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

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

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
>