Sorry to be confusing, I'll try to ask clearer questions
and expose my  
assumptions first.  Part of what I'm assuming is that not
every  
organization will find Cosmo to be the final answer.  I'll
use  
universities as an example, since that's where we've got a
lot of  
awareness of the requirements.  Some universities will want
to use  
Chandler and will want Chandler sharing to work, yet
they'll look for a  
commercial solution, or want use something with edu-specific
features.  
Will they be able to?

The answer to that today is "no", but it's not
hard to get to "yes."
  - To be able to use RPI's CalDAV server, it would have to
support tickets  
and the ability to share other kinds of collections besides
calendars
  - To be able to use Xythos WFS, the universities would
only have to  
convince Xythos to add CalDAV support.
  - To be able to use Slide, somebody would need to add
CalDAV support and  
tickets.

What I meant by "stick with a list of published or
publishable items" is  
that ideally we could tell the potential organizational
users of Chandler  
a short list of free and public specifications that a
fully-functional  
Chandler sharing server would have to support.

How far short of this ideal do we actually fall or plan to
fall?  Well...
  - CalDAV isn't a standard yet.  We keep pushing it though
and it will get  
there.
  - Tickets isn't a standard, though at least it's
published, and we could  
reasonably propose standardizing it -- it could become an
Experimental RFC  
pretty easily if somebody (who, me?) made that final push.
  - A custom Chandler format?  While that's a publishable
spec, and it's  
conceivable that other servers could support a custom
Chandler format, is  
it reasonable?  Will we actually do the work and publish the
spec?  Will  
we stick to it and support that custom format for release
after release in  
order to be backwards compatible with older versions of
Cosmo and any  
other server?

I guess part of what I'm asking is "what don't I
know" about  
interoperability with this proposal and part of it is
"what are we willing  
to commit to".
  - Besides the proposed custom format, are there any other
non-standard  
pieces that haven't already made it onto our server
requirements list?
  - Would it be reasonable for us to publish a custom format
 
specification?  By when?
  - Would it be reasonable for us to keep
backwards-compatibility with that  
custom format specification?
  - Is it likely that any other software would want to use
this, besides  
servers who need specifically to interoperate with Chandler?
 (If we did  
something like xCalendar, the answer to this might be a
nuanced "yes")

Lisa

On Mon, 13 Mar 2006 16:37:13 -0800, Morgen Sagen  
<morgenosafoundation.org> wrote:

>
> On Mar 13, 2006, at 4:33 PM, Lisa Dusseault wrote:
>>
>> IMO, the best case would be if we could stick with
a list of published  
>> or publishable items.  Do you think this course is
compatible with that  
>> -- e.g. by publishing this format somewhere?
>>
>> Lisa
>
> Sorry, I don't understand what you mean by "if
we could stick with a  
> list of published or publishable items."
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev"
mailing list
> h
ttp://lists.osafoundation.org/mailman/listinfo/dev


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev"
mailing list
h
ttp://lists.osafoundation.org/mailman/listinfo/dev