OK, say what you will for the logic behind the 9P protocol, but I will die on this hill.
#9P is pretty damn complex, in exactly the same sort of way that the SD protocol is complex.
There are a ton of websites talking about how awesome and simple it is; yet, precious few of these sites actually attempt to write their own implementation from scratch. Even Writing a 9P Server from Scratch relies heavily on pre-existing infrastructure.
It might be simple compared to NFS, AFS, or other distributed filesystems. But, in absolute terms, it's still damn complex.
In particular, my beefs include:
I can see the manage for clients to manage tags; but, WTF is up with Fids? Why do I have to manage them? The server is already stateful; it should be managing them for me.
Qids are useless as far as I can see. I can't tell why a client would ever want to know a Qid.
The error handling mechanism of the
Twalk command is just ... bizarre. I think it's because it allows the client to determine where in the path component list the error lies. Wouldn't a simple ordinal in an
Rerror message be as useful? KISS!!!
The Rerror message format is confining. It desperately needs to be redefined as follows, at the very minimum:
Rerror tag code why msg[s]
code provides a meaningful-to-computers error code. The
why field is qualified by
code, and helps in diagnosing why the error occurred in the first place. (For Tripos users, these fields are equivalent to the
res2 fields in an IORequest block.)
msg would be as it currently is.
Twalkis stupidly hard. So many details to keep straight in your head while coding its handler!
I've already written about 350 lines of 9P handling code, and it'll probably be closer to 450 to 500 lines after I've finished implementing Twalk. I haven't even come close to implementing support for read, write, open, close, stat, wstat, etc.
I have no confidence that I'm actually implementing this protocol correctly.
I realize I never explained myself by "exactly the same way as SD protocol" in the above message.
What I meant was that once initialized, reading and writing to a Fid is drop-dead simple. The problem is getting that fid initialized in the first place.
@vertigo Well that's kind of disappointing. I'd always heard it was pretty simple, but yeah, at best compared to NFS or whatever. Closest I've come to implementing anything like that was a very simple FUSE filesystem that only supported the basics. Now THAT was simple.
@freakazoid Fixing FID management and the error reply structure would go a long way towards simplifying the protocol.
@freakazoid This is what I've implemented of 9P so far. https://git.sr.ht/~vertigo/forthbox/tree/master/item/emulator/src/dos.c#L168-350
It's admittedly not a lot of code. But just getting to this point took a lot of mental energy.
A bunch of technomancers in the fediverse. Keep it fairly clean please. This arcology is for all who wash up upon it's digital shore.