Daniel Pittman writes:
> As such, I want to propose an alternate tag to indicate our own
> paths:
>
> "/!/"
>
> This will /not/ trigger either EFS or Ange-FTP when dealing with
> paths. This removes the need for hacking around at a number of
> fundamental levels to avoid treading (too hard) on the toes of
> these tools.
>
> This, I feel, from the point of view of code complexity, is nothing
> but a win.
I agree with you but would like to take it further. How about
reworking the whole syntax along these lines.
/![@enc]/:telnet://[usr[:pwd]@]host1[:port]/ssh://host2/:/path/to/file
^^ ^ ^^ ^^^ ^ ^ ^ ^ ^^^ ^^
A B C F H G I D F E
A tramp-prefix-tramp-name "/!" or "/tramp" or "/:" or "/&"
B tramp-prefix-encoding "@" or ":" or "/[^:]"
C tramp-prefix-first-connection "/:"
D tramp-prefix-next-connection "/[^/:]" or "[^/]/[^/:]" or "/[^:]"
E tramp-prefix-remote-pathname same as C
F tramp-prefix-authority "//:" or "#"
G, H, I, etc. are specific to schemes
C, D, and E are mutually constrained to match at the start. Having F
set to "#" makes parsing easier for them. I suggested "//:" for F to
match the syntax of URIs; see RFC 2396 and 1738.
There would be no "@encoding" clause for an out-of-band method. For
in-band, encoding would be "base64" or "uuencode". We may want to add
other encodings later such as "quoted-printable".
The encoding might also be specified as "b64" or "uu" or "b" or "u".
The protocols could also accept long and short forms, e.g. "telnet",
"tn" and "t" would be equivalent.
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
[EMAIL PROTECTED] -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
