Re: [9fans] 9P writes for directories

[Uriel <uriel99@gmail.com>]

Some of us have been thinking about a 'sane' subset of HTTP plus some
conventions, that could reasonably map to 9p.

The main issue is the huge amounts of crud in the HTTP spec and how to
pick the sensible bits and discard the rest while remaining compatible
with existing implementations; the main convention that needs to be
added is a way to list directory contents, likely using something not
too insane, like JSON.

With some thought and care one could come up with a very simple,
RESTful, and almost 9p-mappable replacement for the stinking bloated
WebDAV and SOAP/XML-RPC abominations.

uriel

On Thu, Mar 26, 2009 at 11:05 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Mar 26, 2009, at 1:54 PM, Eric Van Hensbergen wrote:
>>>
>>> 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.
>
> I believe we're on the same page, but the wording is  not always
> accurate.
>
>> 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,
>
> Interesting point. I guess it all depends on what is the model for
> new nodes to be created in the URI tree. In fact, if I were to complete
> the analogy, then POST to an existing URI (although, nothing really exists
> in the world of URIs) corresponding to a "subdirectory" would be, in fact,
> what you say. A POST/PUT to a non-existing URI could be considered
> a creation of the named resource in its parent. Although I'm not sure that
> such a thing should be always allowed.
>
>> 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.
>
> If you mean PRG (http://en.wikipedia.org/wiki/Post/Redirect/Get) then
> yes.
>
>> I think the critical aspect from the REST/CRUD perspective is that the
>> POST
>> has to be idempotent
>
> Not as per HTTP RFC:
>    http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
>
>>>> 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.
>
> Agreed.
>
> Thanks,
> Roman.
>
> P.S. I wonder if there's a general interest in REST from the Plan9
> folks. I've seen your blog post on the subject, so there's that. It is
> actually quite fun to see how things like Google App Engine and
> http://konstrukt.dk/, etc can reap the same benefits from the elegance
> of FS-aware design. Could it be that with the right approach
> (lib9p/libixp plugin for apache?) writing web services could be
> as much fun as writing filesystems for Plan9?
>