Dear folks, To me suspend and resume is not a fancy feature. It is a must have like all the other conveniences and simplicity that scp provides. I agree with Damien that this will cause multiple protocol versions to float around, but we can't make omelettes without breaking eggs. The question is how important is this feature? I would say it is very basic compared to other fancy features like multiple simultaneous file transfers and all that. 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. Please let me know your thoughts. regards, Girish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Girish Venkatachalam wrote:> I would say it is very basic compared to other fancy > features like multiple simultaneous file transfers and > all that.Whether or not a feature is fancy really depends on your needs. I support a community that regularly using OC12s as their lower end long haul paths and 30Gb+ paths at the higher end (I2 and ETF research networks). Once the speed issues with SSH were resolved the two main features they want are a more intelligent approach to multiple file transfers in scp and a resume function (even at 800Mb/s when a 2TB transfer dies 1GB from the end its really annoying). Also just so you know, I was supporting your position regarding the resume feature.> 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.Having had to play with that quite a bit for the HPN patch (www.psc.edu/networking/projects/hpn-ssh) dealing with versioning issues is pretty annoying and it rarely seems to be as straightforward as one would hope. While I'm not saying you shouldn't consider this it can really open up a can of worms. The main reason why I suggested a new incarnation of SCP as opposed to patching the old one was really to get around some of these issues. Chris
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. 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. If you want to work on something that has a change of being committed, then please help improve the sftp client. This means: - Adding recursive transfers (there is already a patch in bugzilla for one side of this) - Supporting a scp-like commandline syntax "sftp -r aaa foo:/bbb" - Improving the performance of multiple file transfers and remote glob operations (pipelining between files, caching attributes, etc.) 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. -d
Hi, On Thu, May 11, 2006 at 05:56:11PM -0700, Girish Venkatachalam wrote:> I agree with Damien that this will cause multiple > protocol versions to float around, but we can't make > omelettes without breaking eggs.So are you going to maintain the necessary code parts for the next 20 years?>From a developer's view, "user must have!" features quite often turnout to be a serious maintenance nightmare, especially if interoperability with old and new versions must be maintained. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de