On Mon, Nov 26, 2018 at 10:24:27AM -0500, Greg Troxel wrote:
> Interesting about putting  plan9 in the middle; that feels like a wart,
> and it's hard to understand how extra protocol translation can make
> things that didn't have a way to be done work.

It is a bit warty, plan9 doesn't have callbacks, so I'm still not sure
how cache invalidation works, which is why optimizing for the no-cache
cache is useful. If something is seriously missing it could always be
developed as a new extension to the existing protocol ('9P2000.C'?) with
the disadvantage that we have to maintain our own clients. Which we
would have to do anyway if we didn't begin with the plan9 protocol.

> I too am really unclear on the "extension" notion.  If this is a set of
> extensions to plan9 that are reasonably portable (say, to all posix
> systems) and implemented in portable FUSE/plan9 code, then that sounds
> fine.  But doing anything that only works on Linux sounds like a step
> backwards.

Extensions are defined in the base protocol, during an initial handshake
the client and server negotiate if both support the same extension and
fallback on the base protocol if not. I guess a client could run the
handshake again with a different proposed extension if it wants to
iterate through a few.

> Can you point to the plan 9 fuse client you recommend?

Haven't tried much of these yet so I can't tell you what the best one
is. I've mostly used the v9fs Linux kernel module, and a libixp based
client, which is plain 9P2000 without extensions.

Here is a random fuse client that seems to support the .u extensions and
claims to be as fast or faster than the Linux kernel implementation.

    https://github.com/svinota/py9p

> Can you explain how authentication works?  Is there crypto in the p9
> protocol?  How are other plan 9 clients on the local machine denied
> access?

No authentication, I still haven't figured out how the official
Tauth/Rauth message flow is supposed to work, I haven't seen a client
use those yet. Any plan9 client can claim to be any user which is why I
want to treat user identities as claimed by different mountpoints
independently and every user will have to prove it's authenticity by
providing a valid Coda token.

There is no crypto in the protocol and we don't deny access. Access is
only local through the unix domain socket that is also used by codacon.

Jan