[9fans] URI scheme for 9P2000 resources

[9fans] URI scheme for 9P2000 resources

[Enrico Weigelt]

Hi folks,


I'd like to encode 9P2000 service locations in to URIs and plan
to define an URI scheme for it.

The scheme should be "9p", obviously. Where to put server name
and port is also obvoius. So for the simple TCP case, we can
use something like:

    9p://localhost:9000/my/path

But where does the protocol type (ie tcp) belong ?
And how to encode local servers (on cmdline/pipe) ?


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] URI scheme for 9P2000 resources

[erik quanstrom]

> The scheme should be "9p", obviously. Where to put server name
> and port is also obvoius. So for the simple TCP case, we can
> use something like:
>
>     9p://localhost:9000/my/path
>

the format for a dial string is proto!server!port.  e.g. tcp!atlas.coraid.com!http.
going with your style this would be

	9p://tcp!localhost!service/my/path

a more regular name would be

	9p://tcp/localhost/service/my/path

(see pike's paper "the hideous name".)

but what is the point of encoding a dial string+path as a url?

- erik

Re: [9fans] URI scheme for 9P2000 resources

[David Arnold]

-->"erik" == erik quanstrom <quanstro@coraid.com> writes:

  erik> the format for a dial string is proto!server!port.
  erik> e.g. tcp!atlas.coraid.com!http. going with your style this
  erik> would be

  erik> 	9p://tcp!localhost!service/my/path

  erik> a more regular name would be

  erik> 	9p://tcp/localhost/service/my/path


the relevant specification is RFC-3986, and especially section 3.

SLP (RFC-2608) gives an example of existing practice using a form like

   9p:tcp://hostname/service/my/path

Subversion uses

   svn+ssh://hostname/my/path

which appears at a quick read to be "better" than SLP's format from
the point of view of RFC-3986 ...




d

Re: [9fans] URI scheme for 9P2000 resources

[Enrico Weigelt]

* David Arnold <davida@pobox.com> wrote:

> the relevant specification is RFC-3986, and especially section 3.
>
> SLP (RFC-2608) gives an example of existing practice using a form like
>
>    9p:tcp://hostname/service/my/path

hmm, is this an valid URL ?

> Subversion uses
>
>    svn+ssh://hostname/my/path

Seems some bit unclean to me, if we would put the transport proto
here. It should be as optional as the port. inetd-style port notation
(ie. 123/tcp) could be nice, but would be incompatible.

Why not

    9p:/proto/hostname:port/my/path

or
    9p://hostname:port.proto/my/path

?


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] URI scheme for 9P2000 resources

[Lyndon Nerenberg]

> the relevant specification is RFC-3986, and especially section 3.

Actually, it's the grammar production for <scheme> in appendix A that's
relevant.  URIs must start with an ALPHA ([A-Za-z]).


--lyndon

   Never hit a man with glasses.  Hit him with a baseball bat.

Re: [9fans] URI scheme for 9P2000 resources

[Enrico Weigelt]

* erik quanstrom <quanstro@coraid.com> wrote:

Hi,

> the format for a dial string is proto!server!port.  e.g. tcp!atlas.coraid.com!http.
> going with your style this would be
>
> 	9p://tcp!localhost!service/my/path
>
> a more regular name would be
>
> 	9p://tcp/localhost/service/my/path

Ok. And what about commandlines (for local servers ?)

> but what is the point of encoding a dial string+path as a url?

Integration in web-like environments, ie. mozilla ?

I'm going to add an minimal 9p client into mozilla. So you can
simply put an 9p url into the browser and have fun ;-)


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [9fans] URI scheme for 9P2000 resources

[erik quanstrom]

>
> > but what is the point of encoding a dial string+path as a url?
>
> Integration in web-like environments, ie. mozilla ?
>
> I'm going to add an minimal 9p client into mozilla. So you can
> simply put an 9p url into the browser and have fun ;-)

mozilla, unlike emacs, is not an operating system.

> Ok. And what about commandlines (for local servers ?)

talking about command lines is a bit odd.  9p servers serve a tree of
files.  9p doesn't have "command line arguments".  you could make
the elements of the path beyond the server root appear to be arguments.

part of the difficulty here is you are trying to stuff different plan 9
concepts into a uri.  command line arguments don't interact with
9p in plan 9.  likewise, dial strings are outside 9p.  putting them
all together is uncharted territory.

- erik

Re: [9fans] URI scheme for 9P2000 resources

[Uriel]

On 6/30/07, erik quanstrom <quanstro@coraid.com> wrote:
> >
> > > but what is the point of encoding a dial string+path as a url?
> >
> > Integration in web-like environments, ie. mozilla ?
> >
> > I'm going to add an minimal 9p client into mozilla. So you can
> > simply put an 9p url into the browser and have fun ;-)
>
> mozilla, unlike emacs, is not an operating system.

You didn't get the Web 2.0 memo? If so, I truly envy you.


> part of the difficulty here is you are trying to stuff different plan 9
> concepts into a uri.  command line arguments don't interact with
> 9p in plan 9.  likewise, dial strings are outside 9p.  putting them
> all together is uncharted territory.

URIs are just hideous, but maybe this is not completely uncharted
territory, at least ken mentioned in some interview that he had been
thinking about a way to have a global (internet-wide) namespace for 9p
servers, would be nice to hear what he had in mind...

uriel

Re: [9fans] URI scheme for 9P2000 resources

[Skip Tavakkolian]

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:')

Re: [9fans] URI scheme for 9P2000 resources

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] URI scheme for 9P2000 resources

[Skip Tavakkolian]

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@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: [9fans] URI scheme for 9P2000 resources

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] URI scheme for 9P2000 resources

[matt]

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: [9fans] URI scheme for 9P2000 resources

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] URI scheme for 9P2000 resources

[Steve Simon]

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: [9fans] URI scheme for 9P2000 resources

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] URI scheme for 9P2000 resources

[erik quanstrom]

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

i think you've invented a new symmetry for uris that no one else
expects or depends on.

i would think that on a unix-like system local connections would
be more useful than tcp.

the symmetry with 9p dial strings would be broken.  that is something
that is depended upon.

- erik

Re: [9fans] URI scheme for 9P2000 resources

[erik quanstrom]

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

this would lead to nondeterministic behavior.  suppose you want to talk
to an authentication service and you expect one to be running on the local
machine.  this could lead to some unpleasant suprises.

i would think that using local instead of tcp would be much preferable.

- erik