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

[Mikeal Rogers]

Ok, let me clarify my argument.

Nobody is saying we're stopping or reducing our support of open  
standards.

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.

-Mikeal