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

[Katie Capps Parlante]

Brian Moseley wrote:
> On 7/14/06, Jared Rhine <jared at wordzoo.com> wrote:
> 
>> If no product of ours exercises the CalDAV features of Cosmo, we will not
>> have a CalDAV test cases.  Even if you wanted to support CalDAV in Cosmo,
>> how could you reasonably ask for QA's time to test features that are 
>> not in
>> Beta?
>>
>> What CalDAV bugs, enhancements, or test cases can rightfully make a
>> prioritization of bugzilla or bug council over any bug/enhancement in our
>> own products?
> 
> it's a good question. the product team's goal of fully implementing
> caldav and atom access may not be perfectly in line with osaf's goals
> for beta. i'd like to hear katie's thoughts on this.

A couple of thoughts...

- The desktop client accesses cosmo through an open protocol. The
current plan is to use CalDAV freebusy reports for freebusy information,
for example. To me, the "level playing field" argument isn't much of a
worry given that we do have some client accessing the server using an 
open protocol. Whatever protocol we use here was going to be the 
protocol used by the web client anyway, as both are going to have to 
support similar feature sets. I don't see a reduction in pressure to 
test and support this protocol because a second client is not going to 
use it. How much this protocol looks like CalDAV is perhaps the more 
interesting argument, and has been brought up in the sharing format 
discussions. Morgen summarizes requirements and proposals here:
http://lists.osafoundation.org/pipermail/cosmo-dev/2006-July/001031.html

- We never had plans for the web client or desktop beta features to
cover all CalDAV functionality. We choose client features based on a
particular compelling experience for the user, not example coverage of
the protocol. If other clients want to use other features, this was
always going to leave us open to questions of priority for implementing
and testing those features.

- If we implement features, we should implement test cases for those
features. If we don't have test cases for server features, we 
essentially don't have the features. (I don't think the responsibility 
falls solely on QA here, btw.)  If we decide to implement a CalDAV 
feature, we should implement a test for that feature.

- I'll point out that we continue to go to interop events and we
continue to log and fix bugs that we discover when the server or desktop
client doesn't work against other clients and servers.

> one thing that hasn't been addressed is that, as an open source
> project, cosmo can benefit from outside contributions, and we can give
> commit access to non-osaf staff to work on things that are of interest
> but not part of osaf's product plan. this includes caldav.

This is a really important point. OSAF as an organization has finite
resources and can't do everything in the full vision in the short term.
We've prioritized a working app that will attract end users over a
complete/reference CalDAV implementation. This does not mean that CalDAV
or Atom aren't in our roadmap. In the short run, if other projects or
individuals need/want the server to have better/more complete CalDAV or
Atom support, it is a perfect opportunity to contribute to this project.

In other words, OSAF does not have the goal of spending whatever 
resources necessary to implement CalDAV, WebDAV or Atom support for any 
project that might want to use the server in any way. If other projects 
want to use the server and their goals don't conflict with ours, we 
absolutely encourage that collaboration. They'd be responsible for doing 
the work that is specifically required for their project goals, 
including test writing. That kind of collaboration is a fantastic 
outcome -- being open to collaboration is one of the benefits we hope to 
get from being an open source project. We already have such 
collaborations going on (e.g. Foxmarks). We should encourage such 
projects to introduce themselves, btw.

> given that we've implemented probably 80% of the protocol, and the
> most useful 80% at that, and that we have demonstrated
> interoperability with a number of clients, i feel reasonably sure that
> a lot of people will get what they need out of what is already in
> cosmo. but the door is wide open for those who need the other 20% to
> contribute patches.

Back to the question 'is fully implementing caldav and atom perfectly in
line with osaf's goals'.

Beyond supporting communication between our own client and server, we 
could have two reasons to implement a protocol like Atom or CalDAV:
(1) support interop with some existing client or server
(2) encourage interop with future clients or servers (or future protocol 
support in existing clients and servers)

For (1), it seems logical to prioritize clients and servers based on how 
that might drive adoption or meet our target users' needs. For example, 
if "casual collaborators" are using other calendars, it makes sense to 
be able to exchange meeting invitations or freebusy information or more 
directly share calendar events. (I'm picking a calendar example because 
it is easy, there are a range of other possibilities of course.) When 
making an argument for adding support for this or that protocol feature, 
the argument is strengthened if we can explain how that helps the target 
users, given existing clients and servers.

The value in (2) is a longer term argument. It is worth doing over the 
long term, and is in our roadmap. The rationale for our priorities is 
that establishing a user base is valuable to almost every aspect of our 
endeavor here, from getting user feedback to developing collaborators to 
making it worthwhile for other projects to make their clients and 
servers interoperate with us using standard protocols.

It is really a matter of what gets implemented first, given finite OSAF 
resources. The generic answer is that some features might not get 
implemented in the beta timeframe, because other work (i.e. a move to 
hibernate or other work to support scalability) takes priority. This was 
going to be true whether or not the web client uses a protocol vs a 
direct api. I look to the team for the specifics as the planning plays 
out. :)

I know that John is working on a strategy proposal for the server, and
I'm sure that will be discussed here before we make concrete decisions.
Once we've hashed through that we should be more clear as an
organization about what specific features are prioritized through the
beta timeframe (and perhaps beyond).

Cheers,
Katie