Re: [9fans] 9P writes for directories

[Eric Van Hensbergen <ericvh@gmail.com>]

On Thu, Mar 26, 2009 at 3:23 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Mar 26, 2009, at 12:44 PM, Eric Van Hensbergen wrote:
>>
>> On Thu, Mar 26, 2009 at 2:31 PM, Roman Shaposhnik <rvs@sun.com> 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