[Cosmo-dev] Re: [Scooby-dev] Cosmo/Scooby Merge (Please read and
comment)
Mikeal Rogers
mikeal at osafoundation.org
Thu Jul 13 15:12:33 PDT 2006
On Jul 13, 2006, at 2:49 PM, John Townsend wrote:
>
> 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.
What Peter is trying to say is that our message seems to be "CalDAV
wasn't good enough so we're not using it". Yes, it doesn't make sense
for scooby to communicate with cosmo via CalDAV, or for that matter
any open protocol, if they are merged. But we aren't saying, "We're
merging them for other reasons and using CalDAV no longer makes
sense", it looks like what we may be saying is that "CalDAV wasn't
good enough so we're not using it and we're merging the products so
that we can communicate directly with the repository". If this isn't
the message we want to express then we should prepare what our
message really is.
>
> 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.
But we have no incentive in the short term to improve our support for
CalDAV.
>
> 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.
As a little exercise, change the words "Cosmo, Scooby, and Chandler"
with "Exchange, Outlook, and Entourage" and replace "ecosystem" with
"platform".
I think this message is beginning to sound more and more like we're
not just giving up on CalDAV, but on open standards in general. We're
certainly saying it's now secondary.
>
> To summarize, I think this merge still supports the goals of
> promoting open standards while providing more support for our
> ecosystem goals.
It doesn't "support" the "the goals of promoting open standards" , if
it insures that it's always a secondary consideration.
>
>> 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.
No, this is the exact opposite of what we are doing with the sharing
format. The sharing format/protocol is an open standard we are
drafting that allows Chandler and Cosmo to store and communicate
information about the resources stored on those two products via an
interface and protocol anyone can use. The move to merge Cosmo and
Scooby is a move to reduce the use of similar open standards to
communicate information about the data stored on cosmo.
>
>>
>> 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.
I agree that the people working here all continue to personally
support and commit themselves to open standards. But the merge seems
to be a move to provide less incentive for this and certainly to
remove it as a requirement to our future development in the
organization.
>
> --> 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
>
> _______________________________________________
> scooby-dev mailing list
> scooby-dev at lists.osafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/scooby-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20060713/2ac93b7c/attachment.html
More information about the cosmo-dev
mailing list