From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 10 Nov 2008 13:56:58 -0800
From: "Roman V. Shaposhnik" <rvs@sun.com>
In-reply-to: <602d022987958658e5d9467747b97ed5@quanstro.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <1226354218.17713.264.camel@goose.sun.com>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <602d022987958658e5d9467747b97ed5@quanstro.net>
Subject: Re: [9fans] Do we have a catalog of 9P servers?
Topicbox-Message-UUID: 396c73b4-ead4-11e9-9d60-3106f5b1d025

On Sat, 2008-11-08 at 06:47 -0500, erik quanstrom wrote:
> > Sure. But that would an argument in favor of the Plan 9/Inferno
> > kernel architecture, not the protocol itself. Nobody's denying
> > that 9P is a perfect match to that kind of kernel architecture.
> > What I'm trying to find out is whether the protocol could stand
> > its own ground even if Plan9 kernel is not serving nor muxing it.
>
> this depends entirely on your criteria and constraints.

Ok, here's a stab at describing my requirement: imagine a situation
where you need to make access to a large variety of existing external
resources (and I really do mean *variety*) be:
   1. transparent to the users
   2. independent of the user's environment
   3. independent of the location of the users
   4. independent of the user's ability to *explicitly* do networking

Most of these existing external resources are already shared using
protocols quite different from 9P. Worse yet, the servers serving
them are not under our control. Thus making them speak 9P at the
end point of a server is not an option.

Now, at this point, one might wonder why not use FUSE and import these
resources directly at the client end-point? The answer is quite simple:
because of MS Windows (#2) and because of the potential inability
to dial out (#4) on demand.

Thanks,
Roman.

P.S. On a similar note I'd like to add that the requirement outlined
above seem to be quite typical in today's world. See, on one hand new
kind of resources (take flickr or youtube as an example) are very
unlikely to be shared using 9P, unless WE can argue that 9P is somehow
radically better (saves bandwidth, etc.) for the resource *maintainer*.
Not an impossible thing to articulate (as some of the responses I've
got to my earlier question indicated -- thank you guys!) but a difficult
one. Why? Well, because the next question you get from the maintainers
is: who can import our resources using 9P on the client side?

I wish 9p:// URL worked out of the box in Firefox, but it doesn't. It is
also not supported by JDK & C#. And even we we stick with the "resources
as regular files" approach on the client you're stuck with mostly POSIX
environment + locking (+caching). POSIX means symlink(2) and mknod(2)
(and locking/caching means a lot of pain and mental masturbation).
Last time I checked, we didn't have consensus on how things like these
are supposed to be handled by 9P.

And finally -- it is ok to say: "they are not supposed to". If that's
our collective answer, that also answers my earlier question -- 9P as
it stands is useless in a situation like I'm in.