- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 6 Nov 1996 16:13:00 -0800
- To: "'Daniel W. Connolly'" <connolly@beach.w3.org>
- Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Not at all!!!! Feature X can be triggered by any media type that is defined to perform that action. So copy would initially be performed through application/copy. There is nothing stopping application/foobar from also doing copy. In addition all the mime types we are defining are versioned. So if you don't like application/copy as we have defined it, no problem, just change the version number in the mime file and implement anything you want. There are no restrictions. We may even want to create a header to indicate the version of the enclosed mime file so you can negotiate on that as well. That is a much more powerful form of negotiation then we currently have with methods. Thus you can negotiate any kind of copy you want. Including querying the server to see if it supports application/foobar. It is generic, negotiable, and brain dead easy to implement. In addition we need to differentiate between requesting an action and performing an action. When you make a copy request nothing actually happens. What you have done is requested that the server take certain actions on your behalf. Conceptually the copy doesn't occur until the server goes out and performs a bunch of GETs and PUTs. A COPY method is meaningless without its content body. Unlike GET or HEAD where all the information about the request is in the header, for operations like COPY, MOVE, and RENAME, the entity-body contains the critical data. Originally we were going to sidestep this problem by introducing a billion new headers which would allow us to put all the information about a COPY in the header but we understand that this wasn't a good idea. Thus introducing a bunch of new methods buys you nothing. The real action is in the content type. Yaron >-----Original Message----- >From: Daniel W. Connolly [SMTP:connolly@beach.w3.org] >Sent: Tuesday, November 05, 1996 8:59 PM >To: Roy T. Fielding >Cc: w3c-dist-auth@w3.org >Subject: Re: POST vs. separate methods > >In message <199611060431.AA10149@mta4.nts.uci.edu>, "Roy T. Fielding" writes: >> >>I understand that it is possible to ignore that and to do everything under >>a single method and to encapsulate the semantics of the request within >>the message body. The reason we don't do that is [...] >>it also frees the media type from having any semantics other than >>"this is the format of what is contained within the body." > >Ah! Terribly good point: if we say that feature X is triggered >by using media type MX, then we've lost the ability to use >other data formats to do X; we've lost the traditional >'format negotiation' degree of freedom. > >One way to address that is to make sure MX is a compound (aka >multipart) data format with a typed 'payload' subpart. But >that starts to get contorted Real Fast. > >So I'm in favor of separate methods for COPY, MOVE, RENAME, >and other long-standing filesystem operations. My convictions >are less strong about less traditional idioms like BROWSE, >LOCK, etc., but my intuitions are in the same direction. > >The only time I struggle with the issue is when the operation can be >piggy-backed on GET, PUT, or POST with 'carrier wave' headers; for >example, GET-with-lock could use a GET method with funky headers. >That reduces the: > > C: LOCK R > S: 2xx OK, here's the lock > ---or--- > S: 5xx Huh? what's LOCK? > C: GET R > S: 200 OK, here's the document >conversation to: > C: GET-with-lock R > S: 2xx OK, here's the document and the lock > ---or--- > S: 200 OK, here's the document (doesn't grok with-lock) > >Even that's a bad example, since consuming a resource like a lock >is a goofy thing to do in an idempotent[sic] method like GET. > >Dan >
Received on Wednesday, 6 November 1996 19:13:14 UTC