> Perhaps someone should sit down and write an win32 driver for it ;-)

there is one.

For this we use local Infernos at machines serving resources,
using a dav server to provide the built name space to the native host systems.
Not for devices, but works for most other things.
Devices can be done by adapting their interfaces via wrapper FSs.

>
> 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.
>

I must have missed something. what dav server?

hiro

On Tue, Nov 11, 2008 at 9:45 AM, Fco. J. Ballesteros wrote:
> For this we use local Infernos at machines serving resources,
> using a dav server to provide the built name space to the native host systems.
> Not for devices, but works for most other things.
> Devices can be done by adapting their interfaces via wrapper FSs.
>
>>
>> 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.
>>
>
>

> This approach seems to be flawed on two accounts:
> 1. it forces the server to resolve symlinks and special
> nodes, without an option for the client to do the same.
> That prevents cross-tree symlinks and nodes as the
> points of rendezvous *on the client*. IOW, the following
> will not work:
> $ mknod /test p
> $ echo test >> /test &
> cat /test
> I can buy a point of view that reading on a node that happens
> to be a character device should really bring the data from
> the remote server's device attached to that node. However,
> that point of view is much more difficult to sell for
> FIFOs.
>
> 2. It doesn't let manipulate these special files. IOW,
> readlink(2) fails and so does mknod(2)/symlink(2).

operations like these (symlink, readlink, lock, etc.) that only have
significance at the extremities should not worry the transit relays.
that was the reason for Text/Rext proposal.

regardless, interpretation of the ops in a hetergeneous environment
will be a problem.

On Tue, Nov 11, 2008 at 9:37 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>
> operations like these (symlink, readlink, lock, etc.) that only have
> significance at the extremities should not worry the transit relays.
> that was the reason for Text/Rext proposal.
>
> regardless, interpretation of the ops in a hetergeneous environment
> will be a problem.
>

Transitive mounts aside, why shouldn't intermediates just forward
unknown messages? End-points which receive messages they don't know
how to deal with just return Error and the client adjusts accordingly.
Endpoint interpretation of operations should be well documented to
prevent silliness and invisible hedgehogs named Dimsdale.

I suppose this is the same thing you are saying, I just want to have
separate protocol ops for messages versus a single extension op. I
suppose the difference is largely an implementation decision assuming
your protocol operation space is large enough....

-eric

On Tue, Nov 11, 2008 at 4:28 PM, hiro <23hiro@googlemail.com> wrote:
> I must have missed something. what dav server?
>

We have one for inferno in the octopus. We presented/talked about
it in IWP9 at Volos.



--
- curiosity sKilled the cat

On Tue, Nov 11, 2008 at 4:37 PM, Skip Tavakkolian <9nut@9netics.com> wrote:
>> This approach seems to be flawed on two accounts:
>> 1. it forces the server to resolve symlinks and special
>> nodes, without an option for the client to do the same.
>> That prevents cross-tree symlinks and nodes as the
>> points of rendezvous *on the client*. IOW, the following
>> will not work:
>> $ mknod /test p
>> $ echo test >> /test &
>> cat /test
>> I can buy a point of view that reading on a node that happens
>> to be a character device should really bring the data from
>> the remote server's device attached to that node. However,
>> that point of view is much more difficult to sell for
>> FIFOs.
>>
>> 2. It doesn't let manipulate these special files. IOW,
>> readlink(2) fails and so does mknod(2)/symlink(2).
>
> operations like these (symlink, readlink, lock, etc.) that only have
> significance at the extremities should not worry the transit relays.
> that was the reason for Text/Rext proposal.
>
> regardless, interpretation of the ops in a hetergeneous environment
> will be a problem.

It is not a problem if the ops are Topen/Tread/Twrite (on an
alternative attach), as agreed at the first iwp9, sadly people seems
to forget quite easily, and as brucee points out, lack of vision
prevails, that is what doomed .u and will doom .L and other such silly
and pointless hacks, trying to butcher 9P into becoming FUSE, way to
go, and pray for ten thousand monkeys with typewriters because you
will need them to beat the lunix monkeys at their own game.

(Wasn't the disaster of adding .u to p9p a clear enough indication of
how hopeless that path is?)


Peace

uriel

> I just want to have
> separate protocol ops for messages versus a single extension op. I
> suppose the difference is largely an implementation decision assuming
> your protocol operation space is large enough

the thinking is that it's the least polluting -- in regard to 9P
messages -- while still allowing for many categories of ops.

but almost immediately there has to be a standard for the
extension message content. maybe it could be XML/SOAP

On Tue, Nov 11, 2008 at 8:30 AM, Uriel wrote:

> (Wasn't the disaster of adding .u to p9p a clear enough indication of
> how hopeless that path is?)


no. It just showed that the .u path was wrong. Adding extra ops?
Worked well for me for years, it was easy and simple.

If your idea is better, implement it and show it to us. I'd love to see it.

ron

On Tue, Nov 11, 2008 at 10:36 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>> I just want to have
>> separate protocol ops for messages versus a single extension op. I
>> suppose the difference is largely an implementation decision assuming
>> your protocol operation space is large enough
>
> the thinking is that it's the least polluting -- in regard to 9P
> messages -- while still allowing for many categories of ops.
>
> but almost immediately there has to be a standard for the
> extension message content. maybe it could be XML/SOAP
>

I guess the difference between



and

Text

is lost on me. We've (currently) got a large enough op-code space to
satisfy all the Plan 9 operations, all the Octopus variant operations,
all the Linux VFS API, and still have a hundred or so op-codes to
spare. While I have no doubt the Linux community will figure out a
way to exhaust the number of operations, it is not currently a
practical concern. Using the protocol version specification in
Tversion you can potentially provide alternate sets of operations, but
I think that's worth avoiding.

-eric

On Tue, Nov 11, 2008 at 10:30 AM, Uriel wrote:
>>
>> operations like these (symlink, readlink, lock, etc.) that only have
>> significance at the extremities should not worry the transit relays.
>> that was the reason for Text/Rext proposal.
>>
>> regardless, interpretation of the ops in a hetergeneous environment
>> will be a problem.
>
> It is not a problem if the ops are Topen/Tread/Twrite (on an
> alternative attach), as agreed at the first iwp9, sadly people seems
> to forget quite easily,
>

While pretty on whiteboards, this becomes a bit of bitch in the
implementation (of both the client and the server). The reason folks
want to use 9P on Linux (and other non-Plan 9 things) is the protocols
implementation for both client and server is simple and
straightforward. .u failed because implementing the extensions was an
ugly hack, and it is my belief/experience (yes, I tried implementing
extensions this way) would be a similarly ugly hack that wouldn't be
very useful in the end. It was based on my experiences with
attempting to code extensions in such a way along with discussions
with others that led to the current experiment of architecting the
extensions as part of the protocol. Like many things, they are being
developed to satisfy requirements of others so its likely that only a
subset of the operations (if any) will be useful to native Plan 9 or
Inferno. The structure of the extensions is such that they are easily
ignored by the clients or servers which do not implement them (which
wasn't the case with .u).

>
> (Wasn't the disaster of adding .u to p9p a clear enough indication of
> how hopeless that path is?)
>

Yes, .u was a disaster which is why the most powerful supercomputer in
the world is using it for workload distribution and boot-time. It was
a failure, that's why its not being integrated into commercial cluster
toolkits. It was a failure, that's why its not the current defacto
standard for Linux paravirtualized file systems. It was a failure,
that's why there's an RDMA protocol instance developed by
third-parties, and that's why its not being looked at being integrated
into mainframes and why IBM is not considering funding a development
team to support it.

Absolute, complete, utter disaster. Completely hopeless.

-eric

On Wed, Nov 12, 2008 at 2:01 AM, Eric Van Hensbergen wrote:
> On Tue, Nov 11, 2008 at 10:30 AM, Uriel wrote:
>> (Wasn't the disaster of adding .u to p9p a clear enough indication of
>> how hopeless that path is?)
>
> Yes, .u was a disaster which is why the most powerful supercomputer in
> the world is using it for workload distribution and boot-time. It was
> a failure, that's why its not being integrated into commercial cluster
> toolkits. It was a failure, that's why its not the current defacto
> standard for Linux paravirtualized file systems. It was a failure,
> that's why there's an RDMA protocol instance developed by
> third-parties, and that's why its not being looked at being integrated
> into mainframes and why IBM is not considering funding a development
> team to support it.
>
> Absolute, complete, utter disaster. Completely hopeless.

If corporate acceptance is the new measure of success, maybe we
should be using an XML based protocol extension.
-sqweek

Eric Sir,

That's what I proposed in Madrid when introducing [TR]ext. It cannot
hurt. Forward unknown transactions. The destination will Rerror on
crap - it was buggered anyway (as Roy adn HG would say)..

brucee

(back in volos, i went the wrong way and got stuck on skiathos)

On Tue, Nov 11, 2008 at 6:02 PM, Eric Van Hensbergen wrote:
> On Tue, Nov 11, 2008 at 9:37 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>>
>> operations like these (symlink, readlink, lock, etc.) that only have
>> significance at the extremities should not worry the transit relays.
>> that was the reason for Text/Rext proposal.
>>
>> regardless, interpretation of the ops in a hetergeneous environment
>> will be a problem.
>>
>
> Transitive mounts aside, why shouldn't intermediates just forward
> unknown messages? End-points which receive messages they don't know
> how to deal with just return Error and the client adjusts accordingly.
> Endpoint interpretation of operations should be well documented to
> prevent silliness and invisible hedgehogs named Dimsdale.
>
> I suppose this is the same thing you are saying, I just want to have
> separate protocol ops for messages versus a single extension op. I
> suppose the difference is largely an implementation decision assuming
> your protocol operation space is large enough....
>
> -eric
>
>

On Tue, Nov 11, 2008 at 9:54 AM, sqweek wrote:

> If corporate acceptance is the new measure of success, maybe we
> should be using an XML based protocol extension.


Corporate acceptance was always the measure of success. it's the old
measure. And it works, unless you don't need to eat.

ron

On Tue, Nov 11, 2008 at 11:54 AM, sqweek wrote:
>>
>> Absolute, complete, utter disaster. Completely hopeless.
>
> If corporate acceptance is the new measure of success, maybe we
> should be using an XML based protocol extension.
>

I have two measurements of success:
a) what keeps me working on Plan 9 related technologies in a paid position
b) what switches people from using NFS, GPFS, or other horribly
complicated solutions to something closer to Plan 9

..u satisfied both these criteria. I will judge the success of .L on
similar metrics.

Note that I didn't claim that either were optimal solutions, I'm less
clear on how to quantify such a metric. Uriel's opinion of their
worth certainly not among the candidates.

-eric

On Tue, Nov 11, 2008 at 1:18 PM, Bruce Ellis wrote:
> Eric Sir,
>
> That's what I proposed in Madrid when introducing [TR]ext. It cannot
> hurt. Forward unknown transactions. The destination will Rerror on
> crap - it was buggered anyway (as Roy adn HG would say)..
>

Fair enough, what was the op-code(s) for [TR]ext? I need to add them
to my strawman list to make sure I don't inadvertently squash them
with my futzing. Or add them yourself to the wiki under the 9P2010
entry.

-eric

It was N+1. I'm still in greece, though I spoke to tiger last night -
I played Buudy Boy with him and he said woof woof - which means come
home. I'll send you the code on my return.

The puppy has spoken (he's less patient than my sheila).

brucee

On Tue, Nov 11, 2008 at 9:55 PM, Eric Van Hensbergen wrote:
> On Tue, Nov 11, 2008 at 1:18 PM, Bruce Ellis wrote:
>> Eric Sir,
>>
>> That's what I proposed in Madrid when introducing [TR]ext. It cannot
>> hurt. Forward unknown transactions. The destination will Rerror on
>> crap - it was buggered anyway (as Roy adn HG would say)..
>>
>
> Fair enough, what was the op-code(s) for [TR]ext? I need to add them
> to my strawman list to make sure I don't inadvertently squash them
> with my futzing. Or add them yourself to the wiki under the 9P2010
> entry.
>
> -eric
>
>

>> If corporate acceptance is the new measure of success, maybe we
>> should be using an XML based protocol extension.
>
>
> Corporate acceptance was always the measure of success. it's the old
> measure. And it works, unless you don't need to eat.

i'm pretty sure that's not how plan 9 got
written in the first place.

aiming for corporate acceptance doesn't seem
to me to be aiming high enough.

- erik

On Tue, Nov 11, 2008 at 2:51 PM, erik quanstrom wrote:
>>> If corporate acceptance is the new measure of success, maybe we
>>> should be using an XML based protocol extension.
>>
>> Corporate acceptance was always the measure of success. it's the old
>> measure. And it works, unless you don't need to eat.
>
> i'm pretty sure that's not how plan 9 got
> written in the first place.
>
> aiming for corporate acceptance doesn't seem
> to me to be aiming high enough.
>

Given the number of people writing good code for Plan 9 and/or Inferno
now versus 15 years ago it seems like aiming for "higher than
corporate acceptance" doesn't seem to be enough either.

-eric