From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Date: Thu, 26 Mar 2009 13:23:41 -0700 From: Roman Shaposhnik In-reply-to: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: References: <3A09771D-9AD3-4499-A354-A3111F5AD0EF@sun.com> <584ACAD1-5343-4656-AEBC-8C0BFDD5724C@sun.com> Subject: Re: [9fans] 9P writes for directories Topicbox-Message-UUID: ca4491dc-ead4-11e9-9d60-3106f5b1d025 On Mar 26, 2009, at 12:44 PM, Eric Van Hensbergen wrote: > On Thu, Mar 26, 2009 at 2:31 PM, Roman Shaposhnik wrote: >> On Mar 21, 2009, at 12:00 AM, Roman Shaposhnik wrote: >> >> The story here is that we are building a bunch of RESTful APIs >> and my personal preference is to bend HTTP as close to 9P >> as I can get (for obvious reasons). Now, the closest match >> to "create" would be POST with a metadata payload on a >> "subdirectory" URI. But of course, it is not a create at all. >> It really is much closer to write on a subdirectory. Hence the >> question: is there anything that HTTP makes us lose except >> for the transactional nature of create? >> > > So, my understanding is the function of POST to a collection/directory > was to create a new entry in the collection where the ID is assigned > automatically by the collection. The ID created is typically returned > by this operation. If by ID you mean URI, that would be my current understanding as well. Unlike create though, that is guaranteed to create an object in the subdirectory identified by an ID (fid), the POST can return any URI. > This actually sounds more like a (devip style) clone operation to me. I have thought about that too, but became convinced that POST is more like create (or more like write on a subdirectory -- hence the original question). With the clone operation it is the *opening* of the clone device that provides you with a new fid. In HTTP that would be like getting a redirection on GET. Don't you think? > Outside of the ID bit, why wouldn't create suffice? It would (just as Erik pointed out). I guess I was just looking for symmetry (if POST is really a write(*), it should translate into write independent of whether the URI corresponds to a subdirectory or not) and potential pitfalls that made 9P spec disallow writes on subdirectories (and since nobody can identify any of those -- I'll rest my case and proceed with translating POST into different 9P messages depending on the type of the URI). Thanks, Roman. (*) Now, POST really is *not* a write. PUT is. But current generation of browsers can only "write" local files to remote destinations with POST, not PUT. And even with JavaScript that restriction is too painful to overcome :-(