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