[Cosmo-dev] Re: [Scooby-dev] Cosmo/Scooby Merge (Please read and
mikeal at osafoundation.org
Thu Jul 13 16:32:41 PDT 2006
Ok, let me clarify my argument.
Nobody is saying we're stopping or reducing our support of open
Nobody here has the intention of reducing our support of open standards.
BUT, the cases in our recent history in which we have improved our
support of open standards has been driven by a need from our products
connecting and communicating with each other.
Sure, we've said for a long time that full CalDAV support is
secondary, if not below secondary. But when scooby needs to know
something about a calendar, and we currently don't support it in
CalDAV, we get off our asses and write it. Would we have the CalDAV
reports functionality that we have today if scooby didn't need it due
to the nature of it being a cosmo client?
The sharing format is a great example of a problem we are working on
solving in an open format/protocol that eventually will bring a lot
of value to our products. It is driven by a need for a cosmo client
to express new information and be able to query for that information
on cosmo. We will have lots more problems to solve in scooby, many of
which will not be solvable with CalDAV, if we keep them separated
then we drive our own adoption and enhancements/contributions to open
standards -- if we combine them we have a much simpler way of solving
those problems that doesn't relate to anyone beyond cosmo/scooby.
I know that everyone here has a commitment to open standards, but the
way in which we've architected/developed our products up to this
point is what has truly driven our increased use and implementation
of the standards. If we believe that there will be value in having
these implemented in the short term, or to say it differently "If we
want to insure that people will find value in our products outside of
our internal vision" then we should continue on this track.
I want to know the real benefit of such a merge. What is the actual
increase in development time leading up to our ecosystem beta.
> days in a release cycle is mainly irrelevant to me. i'm more excited
> about the opportunity for bobby to become intimately familiar with the
> cosmo internal apis and be able to take over for me if i get hit by a
> bus - or if somebody asks him about them at a con.
I agree that there should be someone other than you who understands
the internal cosmo apis. But i think it's just as valuable for
someone to know the external cosmo apis and how a client would fully
utilize cosmo. Should people on the Chandler team know the inner
workings of the cosmo API's ? We are hiring another cosmo developer,
and another scooby developer, are we really going to be so stretched
for resources that it's this necessary to add another person to the
list of people who could take over development of cosmo?
> and the number of lines of code required for scooby to access the data
> store would drop significantly, as would the number of dependencies it
> has on external libraries.
I understand your argument, but I don't think this totally requires
the kind of merge that is being discussed.
If we say for a minute that scooby connecting directly to the
repository is unnecessary then there is still a ton we could do with
shared libraries and packaging (which we already do) to decrease the
amount of duplicated code.
> i am completely, 100% committed to having multiple kick ass, full
> capable interfaces to cosmo - webdav and it's children caldav and
> carddav, and atom and its children gdata and calatom, along with any
> amazing new things that come along in the future.
I never doubted you for a minute :). But it just seems like this move
would remove much of the drive that has, up until this point,
improved our development of/with open standards.
More information about the cosmo-dev