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

[Brian Moseley]

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

> The real reason we are thinking of this is to prioritize "eco-system work"
> ahead of other work.

well, no, that's not why i suggested it. i did think of it while we
talked about it as an ecosystem feature, but it has advantages beyond
making that one feature palatable to me.

> I don't believe this is a superior architecture, for
> reasons I will describe later. I'd like to know what people think the real
> development impact of this will be, by this I mean in terms of days in a
> release cycle how much faster do we really think this will make improving
> the features we have prioritized as "eco-system work".

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.

> The "benefit" of scooby directly accessing the repository is obvious, scooby
> would no longer have to wait for cosmo to expose a feature and information
> about a resource via a public interface.

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.

> The downside is that we've removed
> our incentive to build those interfaces, which means we have effectively
> said "we won't be supporting people interoperating with our eco-system that
> aren't here at OSAF until after beta, if ever". We would really be ditching
> support of open interfaces to the features we build beyond what we've
> already written.

huh?

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.

we didn't build caldav support specifically so that scooby would talk
it to cosmo. we built it to be interoperable with a wide variety of
clients. that's still a primary goal of the project, whether or not
scooby is merged into cosmo.

> Notice that I've used the term "effectively", nobody is saying outright that
> we are pushing off third party client interop indefinitely, but what
> everyone is saying is that scooby will no longer be the same kind of cosmo
> consumer as another client would be while we're simultaneously saying that
> we are prioritizing "eco-system" work ahead of third party client interop
> work. What this means is that we're ditching it, possibly forever since
> nobody knows the extent to which we may later decide to couple the products,
> many features may be built into the repository that only scooby knows how to
> use.

i think you are reading things into the proposal that are not intended.

> As a hypothetical, what valuable assets would we presumably not have at OSAF
> if scooby were coupled to cosmo from the start. Off the top of my head I can
> see no reason we would have a functional reference java client for CalDAV
> (CalDAV4j, or any CalDAV reports other than Freebusy which was requested by
> Chandler.

nut uh. full caldav support has been planned for cosmo from day one,
including reports.

as far as caldav4j, well, we're not the caldav software foundation.
it's not our moral responsibility to provide client sdks for the
protocols we choose to implement in our servers. there are other
people and other open source projects in the world who can build those
things if they're interested in using them.

> I'm really not convinced that this is a major improvement. Our main
> performance issue now has to do with the repository, not with serializing
> the data in an open format and sending it over the local network to scooby.

just because we've hit one bottleneck right now does not mean that
others do not exist in the system.

> But it also means that we will only be solving problems in a way that
> relates to us and nobody else. We're all smart enough to come up with
> innovative OPEN solutions to these problems that, even if they don't in the
> short term, can translate into solving those problems outside of clients
> built at OSAF.

please tell me what specifically you think is not open about a merged
cosmo/scooby.

> This does not require tight coupling of the products. We could easily have a
> "common" directory that contains all the relevant cross-product code and is
> built into the osaf-server-bundle once.

yes it does. it's about api visibility. the internal api cosmo uses to
access its data store is not exposed to other webapps, even if they
are deployed in the same container. thus, scooby has to use one of the
network protocols to get data in and out of cosmo. with the two merged
into a single webapp, the scooby ui can take advantage of the same
internal apis that the cosmo protocol handlers use, removing several
layers from the stack that data must traverse.

> - Scooby has been designed to be a Web Calendar that uses CalDAV as its data
> transport mechanism.

but that's not its primary purpose. last year we asked ourselves:
what's the primary goal of scooby? to be a reference implementation of
caldav, meant to be used against any caldav server? or to be a
first-order cosmo client, embodying many of the same features that
chandler uses, many of which are not provided for or are explicitly
disallowed in caldav? the answer, surprisingly at the time, turned out
be the latter. using caldav turned out to be the best way to talk to
cosmo, but it wasn't the ultimate point of the product.

> This serves two purposes: 1. It acts as a testbed for
> Cosmo's CalDAV support and 2. In theory, Scooby could be a CalDAV client for
> another CalDAV server. Turns out that we already have Cosmo dependencies
> that eliminate #2.

if you read any of the original documents for scooby, you'll find that
we always said that we would assume cosmo as the backend for the
forseeable future. thus, it's not that we fell asleep at the wheel and
let cosmo dependencies slip in. we architected them from the
beginning.

> We have some cosmo dependencies, like auth. But if a third party developer
> cared enough about it they could contribute code that removed our cosmo
> dependencies or allows for you to limit the feature set in scooby to
> features that relate to servers that implement a subset of the open
> interfaces that scooby uses in cosmo. This is impossible if scooby accesses
> the repository directly.

no it's not. using good programming practices, we program to
interfaces, not implementations. a third party developer could provide
implementations of our service interfaces that use caldav or ldap or
jdbc or talk to a mainframe.

> - Less of a need for CalDAV4j. We would still need it for interoperability
> within Scooby (subscribing to external calendars), but Scooby would be much
> less dependent on the library than it is today. That could lead to some "bit
> rot" or certainly less of a focus on this component in the future.

i recognize that you are a big fan of caldav4j, but it's not our
primary mission. we build the tools we need to meet our organizational
goals. if we find that we no longer need one of those tools, that's
okay. if somebody else needs it, they can submit patches.

> CalDAV4j is a great asset to OSAF and will most likely be used by others
> outside of OSAF and I believe we will get some great contributions and free
> testing because of it. The more we extend cosmo, if we are exposing the
> features via a public interface, the more the scooby team can extend our
> library of java clients that add value to OSAF.

well, you don't need to worry about cosmo supporting multiple
interfaces until the end of time. that is neither here nor there wrt
who builds caldav client libraries.