On Mar 13, 2006, at 5:31 PM, Lisa Dusseault wrote:
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
Will we share anything besides calendar events? If that answer is
yes, then we need to define a format to share items in. By using off-
the-shelf vocabularies, I think that it is reasonable to believe that
other clients and servers could support the format. I understand
that it will take work to strive for backward-compatibility, etc.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
