From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <3A09771D-9AD3-4499-A354-A3111F5AD0EF@sun.com> <584ACAD1-5343-4656-AEBC-8C0BFDD5724C@sun.com> Date: Thu, 26 Mar 2009 15:54:39 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9P writes for directories Topicbox-Message-UUID: ca4ba8fa-ead4-11e9-9d60-3106f5b1d025 On Thu, Mar 26, 2009 at 3:23 PM, Roman Shaposhnik wrote: > 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. I think we have a semantic mismatch, if ID==URI then ID != FID. I don't see where FID's fit in to the REST model (making REST closer to Op, then 9p) > >> 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? > Except that Creates give an ID/path for creation instead of receiving one -- that's the key thing that makes it like clone, the most important bit being that this sort of mechanism avoids collision. Whether or not that is critical depends on how you write your app. I think the main difference here is you are trying to map HTTP syntax to 9P syntax, and I've been thinking of semantics -- an HTTP POST to a subdirectory would equal the opening of a clone file (within that subdirectory), and writing the metadata, a read on that file would return the ID -- this would be done atomically by the HTTP server to service the POST not as a set of HTTP routines. Again - this all depends on what you are actually trying to do with your app as to whether or not clone semantics are necessary. I think the critical aspect from the REST/CRUD perspective is that the POST has to be idempotent which I don't think you can guarantee with just create semantics due to the possibility of collision (but perhaps creates with collision just fail), not sure if that is "expected" from a REST perspective, but it is probably legal. >> 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). > I don't think the symmetry is worth altering the semantics of the protocol -- its likely more trouble than its worth in the long run. -eric