[Cosmo-dev] 0.8 plans

[Brian Moseley]

i realized that i haven't given folks an overview of the 0.8 work i've
been doing. now that other devs are starting to roll off of 0.7, this
seems like a good time.

the tenet of 0.8 is interoperability with the Leopard versions of
Apple's iCal and Calendar Server products (this may be refined but
it's a good working theme). generally this means:

1) finishing up our implementations of RFCs 4918 (WebDAV), 4791
(CalDAV), and 3744 (WebDAV Access Control);

2) adding support for VTODO and VJOURNAL components in CalDAV;

3) implementing the calendar availability draft

there's a lot of detail involved in these items. you can have a look
at http://chandlerproject.org/Journal/BrianMoseleyNotes for a more
exhaustive list, which i'm using as a rough spec until we start moving
things into bugzilla.

i've mostly implemented VTODO and VJOURNAL, although we're not
actually storing those components in the database yet. randy's
tentatively going to start working on VAVAILABILITY.

i've also brushed up a lot of our WebDAV basics, making sure that we
process XML correctly. did you know that a dav property value could
contain mixed XML? neither did i! now we can PROPPATCH and PROPSET
those values correctly. also, WebDAV error responses contain XML
entities describing the errors, something like
<D:error><cosmo:internal-server-error>NullPointerException at
Foo.java:42 ...</cosmo:internal-server-error></D:error>. neat.

the changes that i've already made, and some of those still coming up,
have necessitated large scale refactoring of the dav subsystem.
whereas we used to make heavy use of the jcr-server library from the
Apache Jackrabbit project, we've reduced our dependency on it by
probably 75%. we continue to use it for certain utilities, but all of
the heavy lifting is done by our own code now. the dav subsystem's
design is very similar to abdera's now, and i think it's much clearer
and easier to extend. someday we'll fully remove jcr-server, but
there's no pressing need to do that now.

there are a number of bugs related to protocol interoperability, which
i've classified as enhancements, defects and client-specific issues.
given that we're pressing to move to shorter release cycles and that
i've already been working on 0.8 for a month, i suspect most of those
bugs won't be addressed in 0.8, but we haven't decided anything yet.

i expect that as 0.7 is released and we start to get more of ted's
attention, most of the info on my journal page will migrate to a 0.8
planning page and to bugzilla. i am lobbying to land the 0.8 branch as
soon as 0.7 has been branched, but there's still some question as to
whether the 0.7.x maintenance releases will occur on the trunk or not
(i vote no).