The symbol is Pi. I point that out since it doesn’t render very nicely in my web browser. The URL for the paper is:
http://proness.kix.in/misc/%CF%80p-v2.pdf
Yes, they stuck the symbol into the file name as well. Plan9 people seem to like to do such things just because they invented UTF-8 and were the first to heavily use unicode.
πp intends to replace NFS, SMB/CIFS, HTTP, FTP, 9p2000/Styx (the former plan9 file system), as well as more obscure options like Coda. To that goal, it tries to contain all of the features of those different choices that the authors deemed still useful into one new protocol. Ideas like extended metadata, non-file files (meaning the target on the other end is a file representing a printer, raw disk, or any other sort of device), offline operation, caching, and tolerance for proxies (possibly also caching) in the middle.
So, I think there are some features and decisions to like here. Here are a few.
File versioning can serve two purposes. It can be used to preserve history and it can be used for cache invalidation. πp intends to support both. File versioning to support history is potentially the most handy feature, but it will only work if it is matched with an appropriate on disk file system that supports file versioning. ZFS, one file system that can support versioning (by snapshots, but it doesn’t keep every revision automatically), doesn’t need the file sharing protocol’s help to support looking at the versions from remote systems. On ZFS, the snapshot history can be accessed in a directories .zfs sub-directory.
Without such a file system that supports versioning, πp’s versioning feature can still work for cache invalidation by setting an extended attribute on file systems that have some mechanism for doing so (xattr on some, resource forks on others). Personally, I think that supporting caching is largely only of use when πp is used as a replacement for http, which is further discussed later.
Pipelining would help resolve a major NFS complaint of mine, but it also seems like a large pit of danger. I’d be happy to consider using this protocol, but only for applications that don’t depend on heavy synchronous behavior out of concern about this feature, until it is better proven.
Extended support for special files is great for remotely sharing devices. This was always one of the nice features of plan9 (at least so it sounded, since I never gotten around to using plan9).
OTOH, here are some “features” that I require convincing of.
To replace http, the author’s get rid of the plain text parts. In web development, having those parts be human readable are tremendously useful and I doubt they waste much time in any given session. They also make web connections stateful using this protocol, while being stateless has always been one of http’s strong points (albeit one with some pain). Also extended file attributes seem like a poor alternative to http request and response headers.
Supporting lossy file transmission is rather a head scratcher. Their idea is that it could make for efficient streaming video transport, but still I’m not convinced. Does the client or server decide that the response is to be lossy? It looks like this is a client decision (client choosing by opening the πp connection over TCP versus UDP), however how is the client to know in advance which type of file this is? Is it supposed to query first? That seems ludicrous.
My conclusion though is that if you drop the usage ideas that I don’t like, I don’t see any changes being required in the protocol itself. This idea is obviously in the early states, but it looks like it could be worth exploring when there is more code to run.
On a side note, one thing that did interest me in the paper is that they wrote the initial implementation in Go, and then translate that to C. I didn’t know that Go existed on Plan9, but in looking into that it seems that it still doesn’t quite exist on plan9 since the runtime has yet to be ported. Oh well, one can hope for the future.
It also made me wonder how many plan9 from user space users make use of 9p still?