- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 15 Feb 2005 14:35:30 +0100
- To: Helge Hess <helge.hess@opengroupware.org>
- CC: ietf-http-wg@w3.org
Helge Hess wrote: > > On Feb 15, 2005, at 14:03, Julian Reschke wrote: > >>> 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? > > > 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. Yup, and that's why I think that a supposed-to-be generic method would be the wrong choice here. > ... Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 15 February 2005 13:36:03 UTC