The conclusion regarding resume patch

[Chris Rapier]

Damien Miller wrote:
> On Thu, 11 May 2006, Girish Venkatachalam wrote:
> 
>> To argue Damien's point again, we can have a protocol
>> check in the beginning the way we have to check
>> protocol 1 and 2, in the connect string, and
>> interoperate. 
> 
> You are referring to the SSH protcol negotiation. There is no
> "scp protocol negotiation" which is why we cannot change the scp
> protocol. 

I believe his idea was that by using the versioning information that is 
passed along at the initial negotiation you can tune feature sets to 
suit the server. Being that OpenSSH is already doing this it doesn't 
seem to be a excessive leap to apply it to this. That being said, the 
more that can be done to avoid the necessity of doing this the better.

> It doesn't matter how simple, meritorius or cool your feature is -
> if it changes the protocol then it will not be added to OpenSSH's
> scp implementation.

I understand why OpenSSH doesn't want to bother with scp anymore. Its 
really not the best solution to the problem. However, my feeling is that 
  the developers will not be able to lead the users to water in this 
regard. The users *want* the functionality of scp and so they'll 
continue to use it even though sftp is a better solution.

I think the only way to get rid of scp and lose the need to maintain the 
code ad infinitum is to make some mode of sftp act like scp and then use 
a symbolic link to maintain the scp name. If this isn't going to happen 
then the fact is that people will continue to use scp and will ask for 
improvements to, and submit patches for, scp.

>  - Supporting a scp-like commandline syntax "sftp -r aaa foo:/bbb"

Of course to replace scp you'll need to copy most if not all of the 
command line structure syntax or its going to break thousands of 
scripts. I've actually talked to a couple of hundred users (people I met 
at various academic and industry high performance computing conferences) 
about this issue. A good percentage don't even know about sftp (no, they 
aren't idiots) and those that do want the simplicity of the scp 
interface. I've asked them about replacements to scp and they've also 
said they're only really interested in drop in replacements because they 
don't want the hassle of fixing a multitude of scripts, cronjobs, and so 
forth.


>  - Improving the performance of multiple file transfers and remote
>    glob operations (pipelining between files, caching attributes, etc.)

So this interests me - what is the problem with multiple file transfers?

> Implementing the scp features that are currently missing in our sftp
> client is probably only a few days' work and would provide a much more
> sane base to implement new features like the one you propose.

My feeling is that the scp like functionality would probably be the most 
fruitful avenue at this time. It means on the next release you could 
just get rid of all the scp code. Then if anyone asks to patch scp you 
can say "what scp? its just a link to sftp" :)

Has anyone looked at the performance differentials between scp and sftp 
for common tasks?