Subject: Re: [Groupdav] [Fwd: draft-reschke-http-addmember-00]

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Feb 2005 14:03:44 +0100

Helge Hess wrote:
> Hi Julian,
> 
> On Feb 15, 2005, at 12:59, Julian Reschke wrote:
> 
>> recently different communities (caldav/groupdav, atompup (protocol
>> part)) have been discussing how to use HTTP to author new resources when
>> the URL namespace is completely server-controlled, thus PUT just doesn't
>> fit well.
> 
> 
> I still disagree (apparently CalDAV does too), but anyway ;-)
> 
>> I've submitted a first draft as "draft-reschke-http-addmember-00". Note
>> that it also contains an appendix covering possible alternative 
>> approaches.
> 
> 
> If we create a new method, I would like to ask for the possibility to 
> return multiple resources. The one situation which doesn't fit well with 
> PUT+location is a PUT of a cyclic event which is flattened by the server 
> to multiple resources.

So how would you define the semantics for that in a generic way? A 
multi-part request body?

(please follow up on [email-masked])

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Helge Hess <[email-masked]>
Date: Tue, 15 Feb 2005 14:17:30 +0100

On Feb 15, 2005, at 14:03, Julian Reschke wrote:
>> return multiple resources. The one situation which doesn't fit well 
>> with PUT+location is a PUT of a cyclic event which is flattened by 
>> the server to multiple resources.

No, the request body is just one entity. The difference is that the 
server might decide to split the resource provided by the request into 
multiple resources on the server.

The example is in the quote above, you ADDMEMBER an iCalendar entity 
which contains a recurrence rule. A lot of servers do not work with 
calculated recurrences as in iCal, but rather maintain a recurrence as 
a set of individual events. So if the requests arrives at such a 
server, it would create n different resources for a single request 
entity.
It would be nice to be able to report that fact to the client.

Actually I'm not sure whether something like this belongs into a core 
HTTP draft, I think the mentioned example is the only one which comes 
to my mind which requires that type of a response.

Well, maybe another one: you ADDMEMBER a vCard which contains 
firstname/lastname and a company. In a lot of systems company contacts 
and person contacts are stored in different entities. So the vCard 
might be split into two entities.

regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Feb 2005 14:35:30 +0100

Helge Hess wrote:
> calculated recurrences as in iCal, but rather maintain a recurrence as a 
> set of individual events. So if the requests arrives at such a server, 
> it would create n different resources for a single request entity.
> HTTP draft, I think the mentioned example is the only one which comes to 
> my mind which requires that type of a response.

Yup, and that's why I think that a supposed-to-be generic method would 
be the wrong choice here.

> ...

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 15 Feb 2005 13:47:26 +0000

Helge Hess wrote:
> calculated recurrences as in iCal, but rather maintain a recurrence
> as a set of individual events. So if the requests arrives at such a
> entity.  It would be nice to be able to report that fact to the
> client.

On some servers, a recurrence could generate an infinite number of
events, couldn't it?

-- Jamie

---

From: Helge Hess <[email-masked]>
Date: Tue, 15 Feb 2005 14:57:44 +0100

> On some servers, a recurrence could generate an infinite number of

No, infinite recurrences would be rejected as an unsupported entity 
(but thats more a topic for the CalDAV or GroupDAV list).
The same would be true for very large sequences (eg they could be 403 
Forbidden).

regards,
   Helge