URL filename syntax?

URL filename syntax?

[Kai Großjohann]

Is it desirable to use URL-like syntax for remote files?

Currently, Tramp uses this format:

    /method:user@host:localname

My idea is to use

    /method://user@host/localname

where the initial slash is optional.  The initial slash is needed to
provide the old magic slash behavior.

There are some issues with this:

* The URL syntax should be as close to the standard as possible.  But
  the ftp URL RFC states that an ftp URL looks like this:

      ftp://user@host/component1/component2/.../componentN

  where each component can be a string or empty.  The semantics are
  that the user agend does "CWD component1" followed by "CWD
  component2" and so on.

  This means that ftp://user@host/etc/motd refers to the file
  ~user/etc/motd on the remote host, as do ftp://user@host//etc/motd
  and ftp://user@host/a/b/c//etc/motd.  In order to reference
  /etc/motd on the remote host, one has to use
  ftp://user@host/%2Fetc/motd.

  I think we can't require our users to type %2F in such cases, and
  therefore I propose to change the ftp URL syntax to interpret
  ftp://user@host//foo as the file /foo on the remote host.  (And
  ftp://user@host/foo refers to ~user/foo.)

* Tramp allows to omit the method.  How do I do that with URLs?

* Tramp also supports multi-hop connections, with a syntax like

    /multi:hop1:hop2:...:hopN:localname

  where hopI looks like hop-method:user@host.  So, for example,

    /multi:telnet:kai@marvin:su:root@localhost:/etc/passwd

  means to use telnet to log in as user kai on marvin, then use
  /bin/su there to become root, then access the file /etc/passwd.

  In the rare case where one would like to access a file/directory
  whose name contains a colon, one can add slashes.  So to access the
  file "foo:bar" in root's homedir, one could use

    /multi:telnet:kai@marvin:su:root@localhost:~/foo:bar

  which is unambiguous.

  Clearly, multi://telnet:kai@marvin/su:root@localhost/foo:bar will
  not work so well...  Hm.  But I could support ~, too, so this would
  become multi://telnet:kai@marvin/su:root@localhost/~/foo:bar which
  is unambiguous.

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: URL filename syntax?

[Kim F. Storm]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> Is it desirable to use URL-like syntax for remote files?

Summary: No.


> 
> Currently, Tramp uses this format:
> 
>     /method:user@host:localname
> 
> My idea is to use
> 
>     /method://user@host/localname
> 

For normal find-file syntax, // means to discard everything before the
second slash; thus, your suggested change may be hard to get through the
standard read-file-name function (without some changes at the C level).

Also, for a package like ido, the absense of any slashes in the "tramp
part" of the file name is a significant advantage when it comes to
parsing such strings and determining what is what [and given the
obscure ways tramp does method/user/server/file name completion, this
is necessary; look at the code in ido.el, if you don't believe me :-)]

>   I think we can't require our users to type %2F in such cases, and
>   therefore I propose to change the ftp URL syntax to interpret
>   ftp://user@host//foo as the file /foo on the remote host.  (And
>   ftp://user@host/foo refers to ~user/foo.)

Again, you are violating the principle that // has a special meaning
when entering a file name.

> 
> * Tramp allows to omit the method.  How do I do that with URLs?

///user@host/localname

[things get worse, right?]

> 
> * Tramp also supports multi-hop connections, with a syntax like
> 
>     /multi:hop1:hop2:...:hopN:localname
> 
>   where hopI looks like hop-method:user@host.  So, for example,
> 
>     /multi:telnet:kai@marvin:su:root@localhost:/etc/passwd
> 
>   means to use telnet to log in as user kai on marvin, then use
>   /bin/su there to become root, then access the file /etc/passwd.

With URL syntax, you would need to write // to access a file
from the root, ie.

     /multi://telnet:kai@marvin/su:root@localhost//etc/passwd
 
or you would open ~root/etc/passwd,  right?

> 
>   In the rare case where one would like to access a file/directory
>   whose name contains a colon, one can add slashes.  So to access the
>   file "foo:bar" in root's homedir, one could use
> 
>     /multi:telnet:kai@marvin:su:root@localhost:~/foo:bar
> 
>   which is unambiguous.

Ok, but I suppose that is a general problem, not specific to using the
URL syntax or not.

> 
>   Clearly, multi://telnet:kai@marvin/su:root@localhost/foo:bar will
>   not work so well...  

Agree! 

>                        Hm.  But I could support ~, too, so this would
>   become multi://telnet:kai@marvin/su:root@localhost/~/foo:bar which
>   is unambiguous.

And ugly.

I definitely prefer the current tramp syntax!  It does the job well,
has a tidy syntax, works well with read-file-name (and ido), and it
doesn't pretend to be something it ain't.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: URL filename syntax?

[Stefan Monnier]

> > Is it desirable to use URL-like syntax for remote files?
> Summary: No.

I think in the abstract: yes.  But since url-handler.el already tries
to do it, you have to be careful not to step on each other's toes.

> For normal find-file syntax, // means to discard everything before the
> second slash; thus, your suggested change may be hard to get through the
> standard read-file-name function (without some changes at the C level).

I think it works OK in practice.  You need to provide an appropriate
file-handler for substitute-in-file-name, which is inconvenient
(since you need to re-implement the env-var expansion code), but
it's nothing too bad.

> >   I think we can't require our users to type %2F in such cases, and
> >   therefore I propose to change the ftp URL syntax to interpret
> >   ftp://user@host//foo as the file /foo on the remote host.  (And
> >   ftp://user@host/foo refers to ~user/foo.)
> 
> Again, you are violating the principle that // has a special meaning
> when entering a file name.

But it's only relevant for file-name entry, so the only question is
whether it's going to surprise people and I'd say that as a user
I'd be rather happy to be able to enter a URL even if that means
that I might sometimes need to C-a C-k rather than just appending
the absolute name of the file I'm looking for.

> > * Tramp allows to omit the method.  How do I do that with URLs?

You don't.  Or you provide a handler for /user@host:/ that turns
the name into a URL, so people can use the old syntax and
it's automatically changed for them.

>      /multi://telnet:kai@marvin/su:root@localhost//etc/passwd
> or you would open ~root/etc/passwd,  right?

The home dir of the user "root" doesn't have to be "/".

> I definitely prefer the current tramp syntax!  It does the job well,
> has a tidy syntax, works well with read-file-name (and ido), and it
> doesn't pretend to be something it ain't.

I can probably agree with the fact that Tramp's syntax is OK and does
the job well.  For ange-ftp it's different: the URL syntax is well
established for FTP whereas it's not for ssh and friends.
I like to be able to copy/paste URLs from email and whatnot and open
them in Emacs without having to adjust the name.  url-handler.el
serves me "well" except for the fact that it's not too robust.


	Stefan

Re: URL filename syntax?

[Oliver Scholz]

storm@cua.dk (Kim F. Storm) writes:

[...]
> I definitely prefer the current tramp syntax!  It does the job well,
> has a tidy syntax, works well with read-file-name (and ido), and it
> doesn't pretend to be something it ain't.
[...]

I'd just like to point out, that an URL syntax has one big advantage
for *new* users: most users are familiar with it already. If they are
told that Emacs can edit remote files, they are probably able to use
Tramp/ange-ftp right away without learning a new syntax.

    Oliver
-- 
25 Germinal an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: URL filename syntax?

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 14 Apr 2003 13:51:04 +0200, kai.grossjohann@gmx.net (Kai =?iso-8859-1?q?Gro=DFjohann?=) wrote:
> 
> Is it desirable to use URL-like syntax for remote files?

I think it is very desirable, but ONLY if the URL syntax is saved
EXACTLY as it is (may be wrapped, but not changed).

My reason: if it is exactly as is, it can be copied (from Emacs
buffer or from another application by cut&paste) and used easily.
If it needs tweaking, it does not worth the effort, and we may use
other, totally unrelated format (like Tramp's).

Because of the file name reading problem, I propose to prefix the
URL in something like "<URL:" (similar to RFC 1738 suggestion, see
<URL:http://www.ietf.org/rfc/rfc1738.txt>).

Ehud.


- -- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE+nDK0LFvTvpjqOY0RAkv7AJ0ZVlCFpPog3NPizwVWtMRRLDMWywCdEa3x
AAb5L8yMaNviOGlMIfR9/pE=
=H2Se
-----END PGP SIGNATURE-----

Re: URL filename syntax?

[Kai Großjohann]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> On Mon, 14 Apr 2003 13:51:04 +0200, kai.grossjohann@gmx.net (Kai =?iso-8859-1?q?Gro=DFjohann?=) wrote:
>> 
>> Is it desirable to use URL-like syntax for remote files?
>
> I think it is very desirable, but ONLY if the URL syntax is saved
> EXACTLY as it is (may be wrapped, but not changed).

Are you talking about my suggestion of changing ftp://user@host//foo
to mean the same as ftp://user@host/%2Ffoo, instead of
ftp://user@host/foo?

It's not quite clear what you want:

(a) ftp://user@host/%2Ffoo must have the standard meaning, or
(b) ftp://user@host//foo must have the standard meaning (ie, same as
    ftp://user@host/foo), or
(c) both.

I agree on (a).  But for (b) I'd say the added convenience outweighs
the slight incompatibility with the standard.

(And Tramp is incompatible with the standard anyway, since it mostly
supports URL schemes like ssh, scp, su, smb, and rsync, which are not
standardized.)
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: URL filename syntax?

[Ehud Karni]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 15 Apr 2003 21:19:15 +0200, kai.grossjohann@gmx.net (Kai =?iso-8859-1?q?Gro=DFjohann?=) wrote:
> 
> Are you talking about my suggestion of changing ftp://user@host//foo
> to mean the same as ftp://user@host/%2Ffoo, instead of
> ftp://user@host/foo?

No. I'm talking about the general principal - any legal URL should work
without modification. If `wget' can transfer it, Emacs should be able
to edit it in a buffer (It may be read only).
e.g. https://www.name.tld/foo/bar.html 

> It's not quite clear what you want:
> 
> (a) ftp://user@host/%2Ffoo must have the standard meaning, or
> (b) ftp://user@host//foo must have the standard meaning (ie, same as
>     ftp://user@host/foo), or
> (c) both.
> 
> I agree on (a).  But for (b) I'd say the added convenience outweighs
> the slight incompatibility with the standard.

(a) must be supported (any legal URL should work).
(b) MAY be supported - improvements are welcomed.

> (And Tramp is incompatible with the standard anyway, since it mostly
> supports URL schemes like ssh, scp, su, smb, and rsync, which are not
> standardized.)

If there is no standard - there is no incompatibility.
If there will be standard for any of these methods - it should be
supported (note that the ftp standard is NOT supported).

Ehud.


- -- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry
-----BEGIN PGP SIGNATURE-----
Comment: use http://www.keyserver.net/ to get my key (and others)

iD8DBQE+nHeILFvTvpjqOY0RAg9bAJ9wQ2rouMKFpYZmDPSocYGjKfVkywCeN0Gg
qDz38qBiVxPg+8ZM73MaHVw=
=JCKo
-----END PGP SIGNATURE-----

Re: URL filename syntax?

[Kai Großjohann]

"Ehud Karni" <ehud@unix.mvs.co.il> writes:

> On Tue, 15 Apr 2003 21:19:15 +0200, kai.grossjohann@gmx.net (Kai =?iso-8859-1?q?Gro=DFjohann?=) wrote:
>> 
>> Are you talking about my suggestion of changing ftp://user@host//foo
>> to mean the same as ftp://user@host/%2Ffoo, instead of
>> ftp://user@host/foo?
>
> No. I'm talking about the general principal - any legal URL should work
> without modification. If `wget' can transfer it, Emacs should be able
> to edit it in a buffer (It may be read only).
> e.g. https://www.name.tld/foo/bar.html 

Maybe Tramp does not support http and https URLs initially.

>> It's not quite clear what you want:
>> 
>> (a) ftp://user@host/%2Ffoo must have the standard meaning, or
>> (b) ftp://user@host//foo must have the standard meaning (ie, same as
>>     ftp://user@host/foo), or
>> (c) both.
>> 
>> I agree on (a).  But for (b) I'd say the added convenience outweighs
>> the slight incompatibility with the standard.
>
> (a) must be supported (any legal URL should work).
> (b) MAY be supported - improvements are welcomed.

Okay.  It seems that ftp://user@host//foo is an illegal URL, so I can
assign any meaning to it that I like.  Hence, I'll define it to mean
the same thing as ftp://user@host/%2Ffoo.

Do you object?

>> (And Tramp is incompatible with the standard anyway, since it mostly
>> supports URL schemes like ssh, scp, su, smb, and rsync, which are not
>> standardized.)
>
> If there is no standard - there is no incompatibility.
> If there will be standard for any of these methods - it should be
> supported

Yes.

Though I am afraid that there might be a standard which defines some
completely useless meaning to these URLs from Tramp's point of view.
For example, if there is ever a standard that says that
ssh://user@host/ should open a terminal window, then Tramp can't
meaningfully support it.  (Tramp will show a dired buffer of the home
dir of that user on that host instead.)

> (note that the ftp standard is NOT supported).

The ftp standard is not supported by whom?

Tramp does not currently use URL-like syntax, but it does support ftp
(on Emacs, via Ange-FTP).
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: URL filename syntax?

[Stephen J. Turnbull]

>>>>> "Kai" == Kai Großjohann <kai.grossjohann@gmx.net> writes:

    Kai> Okay.  It seems that ftp://user@host//foo is an illegal URL,
    Kai> so I can assign any meaning to it that I like.

It's not.  (If you're referring to my statement on another channel, it
was incorrect, and I tried to admit that; if it was unclear, my
apologies.)

Empty components in the url-path are legal in general (non-opaque)
schemes (such as FTP, cf RFC 2396 Appendix A).  In particular, they're
legal in FTP URLs as well as defined in RFC 1738, Sec. 3.2.2.

    Kai> Hence, I'll define it to mean the same thing as
    Kai> ftp://user@host/%2Ffoo.

    Kai> Do you object?

Do you intend to ensure that that definition is consistent throughout
all the possible ways of exporting URLs from Emacs to other apps?
(Eg, fix shell-mode and comint to recognize and convert Tramp URLs
being passed to wget and the X selection mechanism to recognize and
convert "Tramp URLs" in case of pasting to Mozilla!)

I consider that property very desirable.  Exactly those users who
don't grok %2F are going to be the ones who _need_ those conversions.
I think that that is what Ehud wants, too.

Kai said:

    >>> (And Tramp is incompatible with the standard anyway, since it
    >>> mostly supports URL schemes like ssh, scp, su, smb, and rsync,
    >>> which are not standardized.)

Ehud replied:

    >> If there is no standard - there is no incompatibility.

RFC 2396 and RFC 2718 should be considered carefully.  Especially
since one way to prevent schemes from being defined incompatibly later
is to register them.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.