Re: The conclusion regarding resume patch

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?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev