[9fans] The Web9 Project - Plan9

This is a discussion on [9fans] The Web9 Project - Plan9 ; Hi, Following a request for more information on the project, here are a few details: a) PHP bindings to libixp (client-only; server portion currently being worked on). I will probably try to get this included as a standard module in ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: [9fans] The Web9 Project

  1. [9fans] The Web9 Project

    Hi,

    Following a request for more information on the project, here are a
    few details:

    a) PHP bindings to libixp (client-only; server portion currently
    being worked on). I will probably try to get this included as a
    standard module in the PHP distribution.

    b) JS9P - Implementation of the 9P protocol in Javascript. You can
    create and parse auth messages, but authentication is not supported
    at a higher level. The library provides methods to only create and
    parse binary 9P messages, since JS doesn't have native networking
    functionality. The actual transport can be done by either using the
    Mozilla JS-XPCOM extensions (see below) - or using XMLHttpRequests -
    (a sample has implemented - visit the Web9 site for more info).

    c) "Angled", a firefox extension to read files of a 9P serve right in
    the browser (uses JS9P). For example, typing in ninep://tcp!
    sources.cs.bell-labs.com!564/plan9/LICENSE into the address bar will
    return that file. Text and Images are shown in the browser itself,
    while other binary files trigger a download request. I'm still trying
    to figure out what is the best kind of interface to offer write/
    modify capabilities for the extension is.

    The work is a result of the Summer of Code 2007. You can clone the hg
    repository: http://code.kix.in/hg/web9 or view the code at http://
    code.kix.in/projects/web9/browser (there is also a mirror of the code
    at gsoc.cat-v.org)
    I'm also currently working on a pure PHP implementation of 9P,
    scheduled for inclusion at PEAR (pear.php.net) as the Net_9P package.

    Regards,
    --
    Anant

  2. Re: [9fans] The Web9 Project

    nice!

    for an eyecandy application, you might want to consider integrating
    with something like eyeos (eyeos.org) or similar php based systems.

    have you compared its performance to webdav?

    > Hi,
    >
    > Following a request for more information on the project, here are a
    > few details:
    >
    > a) PHP bindings to libixp (client-only; server portion currently
    > being worked on). I will probably try to get this included as a
    > standard module in the PHP distribution.
    >
    > b) JS9P - Implementation of the 9P protocol in Javascript. You can
    > create and parse auth messages, but authentication is not supported
    > at a higher level. The library provides methods to only create and
    > parse binary 9P messages, since JS doesn't have native networking
    > functionality. The actual transport can be done by either using the
    > Mozilla JS-XPCOM extensions (see below) - or using XMLHttpRequests -
    > (a sample has implemented - visit the Web9 site for more info).
    >
    > c) "Angled", a firefox extension to read files of a 9P serve right in
    > the browser (uses JS9P). For example, typing in ninep://tcp!
    > sources.cs.bell-labs.com!564/plan9/LICENSE into the address bar will
    > return that file. Text and Images are shown in the browser itself,
    > while other binary files trigger a download request. I'm still trying
    > to figure out what is the best kind of interface to offer write/
    > modify capabilities for the extension is.
    >
    > The work is a result of the Summer of Code 2007. You can clone the hg
    > repository: http://code.kix.in/hg/web9 or view the code at http://
    > code.kix.in/projects/web9/browser (there is also a mirror of the code
    > at gsoc.cat-v.org)
    > I'm also currently working on a pure PHP implementation of 9P,
    > scheduled for inclusion at PEAR (pear.php.net) as the Net_9P package.
    >
    > Regards,
    > --
    > Anant



  3. Re: [9fans] The Web9 Project

    > for an eyecandy application, you might want to consider integrating
    > with something like eyeos (eyeos.org) or similar php based systems.


    eyeos seems quite interesting, thanks for the pointer. Another
    interesting application that is possible is a drawterm plugin for
    firefox that uses Angled.

    > have you compared its performance to webdav?


    I don't have any numbers with me, but I would expect 9P to work
    faster than WebDAV since 9P works one layer below HTTP.
    Implementation details aside, header-overhead in itself makes WebDAV
    a less of a competitor.

    --
    Anant

  4. Re: [9fans] The Web9 Project

    > > have you compared its performance to webdav?
    >
    > I don't have any numbers with me, but I would expect 9P to work
    > faster than WebDAV since 9P works one layer below HTTP.
    > Implementation details aside, header-overhead in itself makes WebDAV
    > a less of a competitor.


    Maybe, if you have ridiculously low latency. Which is one of the
    reasons I would like to see the latency issues addressed, so 9P
    services can work well over non-LAN networks. Maybe we can finally
    agree on a solution for this at this year's IWP9?

    Best wishes

    uriel

  5. Re: [9fans] The Web9 Project

    We already agreed on a solution. Nobody is interested in implementing it.

    On 9/8/07, Uriel wrote:
    > > > have you compared its performance to webdav?

    > >
    > > I don't have any numbers with me, but I would expect 9P to work
    > > faster than WebDAV since 9P works one layer below HTTP.
    > > Implementation details aside, header-overhead in itself makes WebDAV
    > > a less of a competitor.

    >
    > Maybe, if you have ridiculously low latency. Which is one of the
    > reasons I would like to see the latency issues addressed, so 9P
    > services can work well over non-LAN networks. Maybe we can finally
    > agree on a solution for this at this year's IWP9?
    >
    > Best wishes
    >
    > uriel
    >
    >


  6. Re: [9fans] The Web9 Project

    On 9/9/07, Latchesar Ionkov wrote:
    > We already agreed on a solution. Nobody is interested in implementing it.
    >


    Well, I started indeed. But then noticed that I needed just a
    different protocol and
    went for it. I may try again in the future with what I learned from
    our current attempt.

  7. Re: [9fans] The Web9 Project

    > We already agreed on a solution. Nobody is interested in implementing it.
    >
    > On 9/8/07, Uriel wrote:
    >> > > have you compared its performance to webdav?
    >> >
    >> > I don't have any numbers with me, but I would expect 9P to work
    >> > faster than WebDAV since 9P works one layer below HTTP.
    >> > Implementation details aside, header-overhead in itself makes WebDAV
    >> > a less of a competitor.

    >>
    >> Maybe, if you have ridiculously low latency. Which is one of the
    >> reasons I would like to see the latency issues addressed, so 9P
    >> services can work well over non-LAN networks. Maybe we can finally
    >> agree on a solution for this at this year's IWP9?


    this topic has come up before. i'm not sure i have a clear picture of the
    problem. would someone give a concrete example?

    without really knowing what the problem is, there is one big thing that
    9p clients traditionally don't do that would be enormously helpful for
    larger files -- readahead. there's nothing in 9p that prevents a client from
    having R outstanding reads at the same time. if l is the rtt latency and
    s is the avg time it takes the fs to service a request, we can try to pick a
    (reasonable) number of outstanding requests R s.t. Rs ≥ l. even if we
    can't, N outstanding should reduce the latency penalty for N packets
    to l, not Nl.

    if instead the problem is lots of little files the proposals i've seen
    are something like bundles of 9p requests. sent en mass to the fs.
    how about the opposite? why not bring the blocks en mass to the fs?
    the remote fs could be treated as a block storage device (we know how
    to do readahead on these things) and the "fs" could be run locally.
    the "fs" a mkfs archive, mbox format, a fossil fs or whatever.

    unfortunately, if the problem is fine-grained, highly concurrent access,
    readahead just won't work.

    - erik


+ Reply to Thread