[9fans] Do we have a catalog of 9P servers? - Plan9

This is a discussion on [9fans] Do we have a catalog of 9P servers? - Plan9 ; > We have at least three different attempts at solving that: 9P2000.u, > Skip's Text/Rext and a "parallel tree" approach, but no consensus(*) Text/Rext are Bruce's idea which he prototyped for Styx. i might have asked for something more crude ...

+ Reply to Thread
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 61 to 80 of 82

Thread: [9fans] Do we have a catalog of 9P servers?

  1. Re: [9fans] Do we have a catalog of 9P servers?

    > We have at least three different attempts at solving that: 9P2000.u,
    > Skip's Text/Rext and a "parallel tree" approach, but no consensus(*)


    Text/Rext are Bruce's idea which he prototyped for Styx. i might have
    asked for something more crude to deal with lock requests.



  2. Re: [9fans] Do we have a catalog of 9P servers?

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

    there is one.



  3. Re: [9fans] Do we have a catalog of 9P servers?

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



  4. Re: [9fans] Do we have a catalog of 9P servers?

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

    >
    >



  5. Re: [9fans] Do we have a catalog of 9P servers?

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



  6. Re: [9fans] Do we have a catalog of 9P servers?

    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


  7. Re: [9fans] Do we have a catalog of 9P servers?

    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


  8. Re: [9fans] Do we have a catalog of 9P servers?

    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


  9. Re: [9fans] Do we have a catalog of 9P servers?

    > 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



  10. Re: [9fans] Do we have a catalog of 9P servers?

    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


  11. Re: [9fans] Do we have a catalog of 9P servers?

    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


  12. Re: [9fans] Do we have a catalog of 9P servers?

    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


  13. Re: [9fans] Do we have a catalog of 9P servers?

    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


  14. Re: [9fans] Do we have a catalog of 9P servers?

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



  15. Re: [9fans] Do we have a catalog of 9P servers?

    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


  16. Re: [9fans] Do we have a catalog of 9P servers?

    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


  17. Re: [9fans] Do we have a catalog of 9P servers?

    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


  18. Re: [9fans] Do we have a catalog of 9P servers?

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



  19. Re: [9fans] Do we have a catalog of 9P servers?

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



  20. Re: [9fans] Do we have a catalog of 9P servers?

    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


+ Reply to Thread
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast