From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Tue, 11 Nov 2008 16:28:17 +0100 From: hiro <23hiro@googlemail.com> To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: <167ecb5d5826c138e3680ff90af47caa@lsub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1226354218.17713.264.camel@goose.sun.com> <167ecb5d5826c138e3680ff90af47caa@lsub.org> Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 3bb63d6c-ead4-11e9-9d60-3106f5b1d025 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. >> > >