Re: [9fans] p9p factotum available for plan 9

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

On Fri, Nov 12, 2010 at 1:55 PM, ron minnich <rminnich@gmail.com> wrote:
>
> That might work but Plan 9 servers currently silently discard T
> messages they don't understand, so this way of determining server
> capabilities can't be used.
>

Silent discard is a bit unfriendly and likely to hang the client.
Returning Rerror for any T message you don't understand is a bit more
friendly (and is what is written in the .L proposal).

> My impression is that if you see .L, then extra operations are
> supported and you assume they'll work; is that true?

Not really, the intent was that servers could implement a subset of
the .L features, and return Rerror for any that they don't.  The
intent was so that a client could degrade gracefully or report lack of
features back to the application/user.  The current client and server
for .L (that I'm aware of) doesn't do this yet (it is still in
development), but that is the intent.

>
> There are other issues with the versioning mechanism however. What if
> a server supports capabilities of two versions, e.g. .L and .op? Do we
> reply
> 9p2000.L+9p2000.op
>

That isn't currently supported by anything (that I am aware of),
although I imagine the right response woul dbe 9p2000.L.op.  Of
course, the op guys specified their stuff as an entirely different
protocol, so not currently a problem.

> It seems we made the first real test of versioning with .u and things
> did not go as we hoped ...

Well, the .u was a "clumsy" design intended to have minimum
interference, but in fact changed the size of certain protocol
messages which really threw a monkey wrench into certain clients or
servers.  The first test of the version stuff was 9p versus 9p2000,
and that worked just fine, but I don't think much was done to test
outside of these two conditions.

>
> As for the uid/gid mess, the simplest way out it seemed to me was to
> send the numbers as strings; done. People can just put the strings for
> the numbers in /etc/passwd; that's what I did anyway.
>

Doesn't really work in multi-account environments where uid on one
system doesn't equal uid on the other system.  Also introduces
potential parse problems.

> And, finally, errno and errstr. Plan 9 speaks strings, Unix integers,
> Windows strings IIRC. The solution for unix clients was reverse
> mapping of errstr to errno, which has not worked well for me. I'd
> still prefer the format I used before:
> sprint(rmsg.error, "%d:%s", errno, errstr);
> and let the client figure out which of these two things it wants.
> Obviously useless for Plan 9 servers but very useful for *nix
> clients/servers, which only want to talk errno. Even if the Plan 9
> client sees an errstr in the number:message format, that could be
> helpful to users.

More or less what we did in .u (it had both, just not in the same string).

In any case, if you are talking to Plan 9, you talk 9P2000 and
everything is as it should be except errors are a little funny.
If you are talking to Linux from Plan 9, you talk 9P2000 and get by.
If you are talking Linux<->Linux then you really should use the Linux
native structures, ids, errcodes, etc.  This is the .L path.

Hey man, IIRC you were Lucho's boss when he did the .u implementation
-- so it's all your fault :P

         -eric