On Tue, 24 Jul 2001, Ed Avis wrote:
> The web page says 'The performance of the external transfer methods
> is generally better than that of the inline methods.'.
Hm. Why does the web page say that? Hm. I think I didn't dare take
it out since I didn't really know it was false. And I've never made
any measurements. I just use the sm method and I'm happy.
> Although the external methods don't have to encode and decode data,
> they do have to open a new connection each time. It seems to me
> that using fsh gets the advantages of both methods - the connection
> is reused, and the files can be transferred quickly (depending on
> how fcp / scp are implemented - I imagine they are pretty sensible).
Sure. I think an out-of-band method for fsh/fcp is a good idea. But
an inline method for fsh might not make much sense.
>>Anyhow, here is something for fsh/fcp:
>
> [tramp-methods Lisp code snipped]
>
>>It is untested. Does it work?
>
> I'll try it. Don't see any reason why it shouldn't, if ordinary fcp
> works.
That's right. If you tell me it works, then I'll add it to the
distribution. Okay?
>>I guess it makes no sense to use fsh rather than ssh for inline
>>methods: both would open a connection only once, and in this case
>>fsh has no advantage.
>
> Well fsh can reuse a connection that's already open (or open a
> connection which is reused later), saving one connection-opening.
> But unless you use a modem link that is not a big saving.
If you think it makes sense to provide an inline fsh method, too, then
don't hesitate to try one and tell me what works, so I can put it in
the distribution.
>>>BTW: one more suggestion - could the default method be to have
>>>TRAMP try several different connection methods in turn until it
>>>finds one that works
>
>>I have intentionally refrained from doing this, since Tramp already
>>tries so many things on the remote end. I didn't want to add
>>another level of complexity to this.
>
> Hmm... but hopefully all you'd do is try one method, and if it
> didn't work close the connection and go on to the next. I don't
> think that is too bad, provided you can clearly determine whether
> the method 'works' or 'fails'.
I agree that it is a good idea to provide the functionality for Tramp
to find the right method on its own. Alas, I haven't found the time
to really think about it, and I couldn't come up with a clean way to
implement it.
But if somebody wants to develop in that direction, please go ahead.
Otherwise, it'll just go on the todo list, I'm afraid.
Btw, another thing which could improve the efficiency of Tramp quite a
bit would be to cut down on the number of commands it has to send to
the remote host even for simple things. For example, the `ls -l'
output could be cached for a while, to provide for quicker filename
completion. Does anybody want to work on that?
> Well, anyway, you knew all that. I suppose I'm just trying to play
> the role of the ignorant but impatient user who wants stuff to Just
> Work as much as possible. This doesn't require much acting :-).
He, he. Maybe my resistance to this feature comes from the fact that
I've already struggled so much with other problems where Tramp does
try to provide auto-detection. It was not pretty. For example,
consider the simple task of finding a shell command which tells you
whether a file (or directory, or device, or pipe) exists. You'd think
that "test -e" is the right command. Except that some shells have a
pretty stupid "test" built-in which doesn't grok the "-e" switch.
Then you could think that "/bin/test -e" or "/usr/bin/test -e"
(depending on the system) might be right. But some systems have a
pretty stupid "/bin/test" or "/usr/bin/test"... you know that. Yet
another idea is "ls -d". This works nicely, except on NetBSD 1.4
where the system-provided "ls" has a bug. On some NetBSD systems,
there is a program "gnuls" which does not have the bug.
I think you can see where this is leading at. The current Tramp
implementation has no choice but to try all of the above commands.
And each command has to be tested with an existing file (it assumes
"/" exists on all Unix systems) as well as a non-existing file (to
catch the "ls -d" bug on NetBSD).
This is one of the many problems of this kind that I've had to deal
with. Maybe now you understand why I sometimes react strangely when
people tell me that they would like Tramp to auto-detect more things.
But nevertheless, I agree that auto-detection (if it can be made to
work right) is a good thing. Is somebody willing to investigate how
to go about this?
kai
--
~/.signature: No such file or directory
