On Wed, Nov 12, 2008 at 9:32 AM, Eris Discordia <[EMAIL PROTECTED]> wrote: > And some stuff for troll-clubbers to club me with: > > 1. What is 9P's edge over text-based protocol X?
It has a simple mapping to basic file operations, which makes it easy to transparently use on the client side. Aside from the debugging tool aux/9pcon, I'm not sure that any plan 9 programs do explicit 9p client calls. > 4. Intelligence is not something peculiar to 9fans and the creators of Plan > 9. Simplicity of design is not something peculiar to 9P. It could appear out > of the blue any day with the latest protocol X. Could do. However, part of the simplicity of 9p stems from its implementation in Plan 9: * 9p doesn't need to worry about the details of auth - that's the responsibility of authsrv + factotum. * 9p doesn't need to support symlinks; the kernel provides that sort of functionality through bind. * 9p doesn't care about different user id mappings because plan 9 only deals with user names (and those are verified by the auth server). It doesn't stop at 9p: * rc/bc/dc/hoc don't need to implement line editing or tab completion because the "terminal" (win from rio/acme) does the job. * rc/awk don't need to explicitly support tcp/ip because we have /net. * fossil doesn't need hardlinks, since venti coalesces identical data blocks. * plan 9 doesn't need to bother with NAT, since you can just import /net from your gateway. Just some examples. But you're right, simplicity of design does happen elsewhere, but it's less likely to arise elsewhere simply because other systems have a lot more crap to deal with. When you're stuck with vt100 emulators, of course every shell implements its own line editing. Of course utf8+tcp/ip support creeps into every app one by one when you don't have a ubiquitous interface to them. Much of plan 9's simplicity comes from its structure and consistency. Note that all the simplicity gains I've listed come from *removing* features. To be able to do that sort of thing it helps to have a system where each component meshes well with the other components. Everything in its right place, so to speak. Not that I'm suggesting plan 9 is 100% perfect, I'm sure there are shortcomings but it makes so much more effort than any other system I've seen as far as elegance goes. > Since protocol X is > supposedly new it will break nothing but if it manages to get a foothold by > its designers _not_ acting up the way the average 9fan does when 9P is > minimally criticized then 9P will be out the window forever. Do you have a > solution to that? Does "improve 9p to the point where no one will even minimally criticise it" count? :) 9p certainly deserves some criticism as it stands - its sensitivity to latency means it works great on a local network, but poorly over something as wide as the internet. Though as Erik pointed out not so long ago, this is a limitation plan 9's 9p client code (and probably the client portion of every other 9p implementation), not the 9p protocol itself. The problem is it forces the server and client to synchronise on every read/write syscall, which results in terrible bandwidth utilisation. Unless we see some remarkable improvements in network technology in the near future, I'd be surprised to see 9p gain any foothold outside local networks before this problem is solved (I should really take a close look at Op). NFS or something similar that is only concerned with serving "regular" files could do a much better job here; 9p is at a disadvantage because it is so general. Having to support arbitrary file semantics makes it difficult to come up with any sort of safe lookahead scheme to avoid waiting for a network round trip on every read()... OTOH, I wonder what semantics are generally used... the common sorts of files are: * "regular files" - a persistent array of bytes, whatever you write() to a certain offset will show up again when you read() the same offset. * ctl files - write()s are not preserved, but affect the state of the file server in some arbitrary way. read()s tend to give some brief information about the state. * event files - read()s block until something interesting happens. write()s might allow bi-directional events. * clone files - a read() of this file creates a new heirachy. I'm sure I've missed something, but readahead is safe for all these constructs except event files, where if you readahead (and get data) but the client closes the file before actually read()-ing the buffered data, you really want to tell the file server to "put back" those events. Buggerit, I'm stumped already. :S -sqweek
