There are proposals for both redirects and bindings (essentially "sym-
links").
Redirect reference I-D is in the RFC queue: http://www.ietf.org/
internet-drafts/draft-ietf-webdav-redirectref-protocol-13.txt (The
only difference between this and an RFC is that they haven't picked
an RFC number yet)
Bind is fairly stable but not yet through the WG: http://www.ietf.org/
internet-drafts/draft-ietf-webdav-bind-14.txt
Lisa
On Mar 5, 2006, at 11:44 AM, Bobby Rullo wrote:
An issue that goes beyond the format ( #3 in your list) of
individual items is the very nature of the repository itself: when
you "PUT" something somewhere in DAV it exists only in that one
place. But in the Chandler repo a resource can exist in multiple
collections. How can we express this with DAV? Do we need to extend
PUT to say "PUT this resource in the following location(s)" (maybe
a MULTIPUT?) What about when you delete an item from a particular
collection, but not delete the resource itself? What about when you
want to add an already existing resource to another collection?
Would adding the concept of symlinks to DAV help (if it doesn't
exist somewhere else as an RFC)? Or should we abandon the notion
that DAV collections have a one to one relationship with Chandler
collections and instead implement this functionality through some
DAV property which contains a list of the collections that a
resource is in (which would make interop problematic) ?
On Mar 5, 2006, at 11:58 AM, Brian Moseley wrote:
what's the alternative?
it seems to me that morgen's trying to figure out:
1) how to avoid storing multiple webdav resources for a single
shared item
2) a sharing format that can fully express all of chandler's
information about a calendar item, even things that might not be
directly expressable by icalendar
3) a sharing format that can cope with stamped items
#1 could be as simple as: use icalendar for calendar items, vcards
for
contacts, and "something else" for everything else.
#2 could be solved for icalendar and vcard with x-properties.
but what about #3? are x-properties sufficient for this purpose? what
about an item that's both an event and a contact - do we store it in
icalendar or vcard? what about an item that's an event, a contact,
and
an email message with a big binary attachment - do we store it in
icalendar, vcard, or mime?
in the chandler repository, an item is basically just a list of types
and a flat list of name/value pair style attributes, right?
couldn't a
very simple xml format address that in a flexible way?
<cosmo:item primarytype="cosmo:event" mixintypes="cosmo:contact,
cosmo:msg">
<cosmo:attr cosmo:name="summary" cosmo:created="xxx"
cosmo:modified="xxx" cosmo:who="bcm">this is an item</cosmo:attr>
<cosmo:attr cosmo:name="firstname" cosmo:created="xxx"
cosmo:modified="xxx" cosmo:who="bcm">brian</cosmo:attr>
<cosmo:attr cosmo:name="to" cosmo:created="xxx"
cosmo:modified="xxx"
cosmo:who="ticket-cafebebedeadbeef">[EMAIL PROTECTED]</
cosmo:attr>
</cosmo:item>
this would not make life difficult for cosmo. when processing a
caldav
or atom request, it could easily convert this to icalendar or
hcalendar. when accepting an event from a caldav or atom client,
cosmo
could convert the icalendar or hcalendar into this format for
indexing
and storage.
supporting a format like this would make cosmo very appealing for
clients other than chandler as well.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
