Ed Avis
Tue, 24 Jul 2001 07:57:22 -0700
On Tue, 24 Jul 2001, Kai [iso-8859-1] Großjohann wrote: >>Could TRAMP include support for fsh >><http://www.lysator.liu.se/fsh/>? >Yes, it should be sufficient to just add some entries to >tramp-methods. Maybe nobody has tried this, however, because Tramp >can already work quite well without fsh. There are two ways to use >Tramp: using an out-of-band method, `scp' (or a similar program) is >invoked for each file transfer. But if you use an inline method, it >just invokes `ssh' once and then keeps the connection open and >transfers the files through that connection. The web page says 'The performance of the external transfer methods is generally better than that of the inline methods.'. 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). >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. >As you can see, I just copied and >pasted it from the default value and replaced ssh with fsh and scp >with fcp. Yup... it's not a difficult change, neither is the change from rsh/rcp to ssh/scp. But it's still nice to have the options in there as part of the distribution. >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. >>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'. The poking around to see what works would happen only once per session at most, maybe even only once ever if the results are saved in a file somewhere. It might be worth doing if it makes TRAMP work first time for the user. It's like configure scripts. No sane application writer would check whether /usr/bin/ld suports shared libraries each and every time before calling it. But for the sake of making stuff work without having to configure it by hand, you might use autoconf. Yes, the configure scripts can do some pretty odd mumbo-jumbo to work out what's available, and they are sometimes difficult to debug when they go wrong. Since the script runs only once and then the result is remembered, you can hold your nose and just accept that this is the price to pay for having software that's easy to install. 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 :-). Maybe the default method could be to prompt the user interactively about what to do: press 0 for ssh, 1 for ftp, 2 for rsh and so on. If the choice the user makes doesn't work, go back to the menu and prompt for another. Perhaps one of the choices could be 'press X to automatically figure it out' (and print a message saying what was chosen). Once the user has selected a method that works, remember it for subsequent requests to the same host. [making a list of methods in order of preference] >Another complication is that it is not clear which method is faster. OK, but you can have some rough idea. For example, rsync will be faster than scp most of the time, and it will never be significantly slower (assuming rsync is well written). >Another complication is that it might not be easy to figure out which >methods work. For example, whether rcp asks for a password can only >be tested by running it, first. That's what I meant - run the methods in turn until one works. If rcp asks for a password that would count as 'fail' because TRAMP doesn't currently support password prompting (AFAIK). >One thing which might be useful, however, is to unify the inline >methods. Tramp could look for something that does base64 encoding, >and if it doesn't find anything, it could fall back to something that >does uuencode. > >But still... for example, Tramp might find a way to do base64 encoding >if you add the right (nonstandard) directory to tramp-remote-path >(where mimencode can be found). Right now, the user is immediately >alerted to this. With your change, the user might wonder why Tramp is >behaving strangely (the reason being that it uses a strange transfer >method). That's kinda a separate issue - the uuencode methods are not reliable due to uuencode not being standardized. Still, I think that printing a warning in the status bar 'using uuencode transfer; may not work correctly' is better than just failing. 80% of the time it will still work, and if it doesn't, the user can proceed to fiddle with the configuration as before. Provided you don't try to deliberately obscure what is going on, there's no harm in trying as hard as possible on the user's behalf to get things working. -- Ed Avis [EMAIL PROTECTED]