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

[Brian Moseley]

On 7/13/06, Mikeal Rogers <mikeal at osafoundation.org> wrote:

> Sure, we've said for a long time that full CalDAV support is
> secondary, if not below secondary.

from day one, the plan was to fully implement caldav. that plan hasn't
changed - we've just expanded our goals.

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

yes, because before scooby was a twinkle in mitch's/lisa's/my eyes,
the cosmo development plan was primarily a staged implementation of
caldav - first MKCALENDAR and the calendar object model, second
reports.

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

let's not get fool ourselves into thinking that the entire reason our
software exists is to implement every standard we can think of and
then to invent more. it's great when we can find standard ways to talk
to other people's software. no doubt about it. but everything we do
shouldn't and realistically can't be motivated by that.

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

you're missing the point by thinking that this is the only reason i
proposed the merge.

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

no.. why is that relevant? i don't understand your point.

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

sure. cos then some of us can focus on delivering "ecosystem"
features, and some of us can work on caldav and atom :)

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

no there isn't. trust me on this. i wrote most of it :)

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

at some point you have to trust that when the product team says that a
primary goal of the server is interoperability with a wide range of
non-ecosystem clients, that they will follow through with it. there's
not much more i can say to convince you of that.