Re: URI scheme for 9P2000 resources

if it handles 9p: scheme, it better be 9p, not some dialect based
on implementer's (mis)understanding of it. browser plugins, by virtue of
what they plug into, have a potential to spread fast. it will not serve
anyone if a popular derivation becomes a de facto standard for 9p.

On 6/30/07, Kris Maglione <bsdaemon <at> comcast.net> wrote:
> On Sat, Jun 30, 2007 at 03:54:49PM -0700, Skip Tavakkolian wrote:
> >please don't use '9p:' for the uri scheme.  there will likely be more
> >than one 9p handler plugin for any browser.  make it specific to your
> >application (e.g.  'u9fs:')
>
> I think that this is silly. 9p is a protocol that presends a
> filesystem, just like ftp, file://, smb://. Would it make sense
> to use wsftp://, gnomefs://, samba://? The URI scheme should
> signify the interface, not the implementation.
>
> --
> Kris Maglione
>
> When your opponent is down, kick him.
>
>

Re: URI scheme for 9P2000 resources

On Sat, Jun 30, 2007 at 11:13:23PM -0700, Skip Tavakkolian wrote:
> if it handles 9p: scheme, it better be 9p, not some dialect based
> on implementer's (mis)understanding of it. browser plugins, by virtue of
> what they plug into, have a potential to spread fast. it will not serve
> anyone if a popular derivation becomes a de facto standard for 9p.

While I'd generally be the first to argue such a point, I don't 
see where you see a problem. It should act exactly the same as 
file:, ftp:, http:, smb:, ... The URI format just describes the 
location of a resource. The resource should be handled exactly 
the same as any other resource. The only real problem I see here 
is that the protocol specification. It would be nice to handle unix 
domain sockets, since p9p uses them, but I think any other 
protocol would be superfluous, and should probably be part of 
the resource.

--

-- 
Kris Maglione

The meek shall inherit the earth,
but not its mineral rights.

Re: URI scheme for 9P2000 resources

The problem I forsee is clunks, unless you keep the 9p alive until the 
browser closes you'll have to time them out which is a subject we've 
touch in recently elsewhere.

Re: URI scheme for 9P2000 resources

On Sun, Jul 01, 2007 at 09:54:29AM +0100, matt wrote:
> The problem I forsee is clunks, unless you keep the 9p alive until the 
> browser closes you'll have to time them out which is a subject we've touch 
> in recently elsewhere.

I don't see how it's relevant. The connections to the server 
should probably be handled in whatever way FTP connections are 
handled. Clunks should be handled in the exact same way that 
closes are (they're equivalent). When the connection closes, the 
server should automatically handle clunks, regardless. The 
browser should obviously close the connection before it closes.

--

-- 
Kris Maglione

The longer you wait in line, the greater the
likelihood that you are standing in the wrong line.

Re: URI scheme for 9P2000 resources

I'am no fan of URIs, however if we must have them:

> The only real problem I see here 
> is that the protocol specification. It would be nice to handle unix 
> domain sockets, since p9p uses them, but I think any other 
> protocol would be superfluous, and should probably be part of 
> the resource.

Wouldn't a heuristic be enough here? if the host specified is the localhost
then forst try to attach to a Unix domain socket, if that fails then try
an IN connection to the localhost instead, the port number would become
the socket's path.

If this where ever used on plan9 the name would (I guess) become the name in /srv
where the fd was posted.

this way we have one uniform uri [sic].

-Steve

Re: URI scheme for 9P2000 resources

On Sun, Jul 01, 2007 at 10:05:16AM +0100, Steve Simon wrote:
>Wouldn't a heuristic be enough here? if the host specified is the localhost
>then forst try to attach to a Unix domain socket, if that fails then try
>an IN connection to the localhost instead, the port number would become
>the socket's path.
>
>If this where ever used on plan9 the name would (I guess) become the name in /srv
>where the fd was posted.

That's what I suggested earlier, elsewhere. The point is that it 
has to be decided on, and universal. I'm not happy that it would 
have a different meaning on (say) Windows, though.

9p:///tmp/ns.foo.:0/acme/1/
9p://localhost/tmp/foo
9p://plan9.bell-labs.com:wiki/installing_plan9_on_your_toaster/index.html

But my point was that any protocol other than TCP or unix would 
seem to go unused, and break consistency with other URI types 
(none that I know of allow you to name a protocol). If there 
comes a time when it's a must, something (as suggested) like 
this:

9p-il://ken/cc/

--

-- 
Kris Maglione

Writings prepared without understanding must fail in the
first objective of communication -- informing

Boot Plan 9 on VMWare Workstation

Re: Boot Plan 9 on VMWare Workstation

On 7/1/07, fouRmi Sun <sunrui82 <at> gmail.com> wrote:
> Also another question, what is the exact filesize of the CD image. I mean
> the ISO file. I download it twice but got two different sizes of image. One
> of them is 267 MB (280,584,192 bytes). Is it correct? Or there may be some
> errors while downloading.

Did you download these on the same day? The cd image is built every
night from the latest sources, so if you downloaded them on different
days these different sizes are to be expected. See
http://plan9.bell-labs.com/plan9checksums.txt for the checksums of the
image.

Greetings, Sander.

Re: Boot Plan 9 on VMWare Workstation

Re: Announce: standalone libixp

>Especially if you don't have evrything in standard locations 
>(ie. on crosscompiling), there's no need for laying hands on

why wouldn't things be in standard locations when cross-compiling?