Hello, I apologize if this isn't the right place to post about the Google Summer of Code; if so, I would appreciate guidance toward the correct list. If this is the correct list, I would appreciate answers to the message below. Thanks. -----Original Message----- From: Jawaad Ahmad <jawaadahmad32 at webster.edu> To: djm at openssh.com Subject: OpenSSH GSoC Project Date: Thu, 19 Mar 2009 15:36:51 -0400 Damien, I am a student at Webster university, and I am interested in participating the the Summer of Code this year. I noticed your project idea regarding renovating sftp to improve its command-line interface. Can you tell me more about this? For this project, I assume you have certain key features in mind besides recursive uploads/downloads via the command-line interface. In addition, by "command-line interface", I assume you mean the "sftp" command line and not the shell in which we enter when we run sftp, correct? Also, I'm curious about the rationale for this. Why beef up sftp to handle this if scp already takes care of it? Do you envision cases in which scp is available but sftp is not? Thanks, Jawaad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090323/3ddd0323/attachment.bin
On Mon, 23 Mar 2009, Jawaad Ahmad wrote:>Also, I'm curious about the rationale for this. Why beef up sftp to >handle this if scp already takes care of it? Do you envision cases in >which scp is available but sftp is not?SFTP is a different protocol, a real one, and while still in a draft, will hopefully become an RFC some day. It's rather a file system protocol now. See this: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ in contrast to that, SCP is just an RCP over SSH link. Very simple, not extensible, meant to be a quick replacement for rcp(1). http://blogs.sun.com/janp/entry/how_the_scp_protocol_works if sftp(1) command can do all what scp(1) can do then users could stop using scp completely, and preferrably just link it to sftp. J. -- Jan Pechanec
Hi Jawaad, Jawaad Ahmad wrote:> I apologize if this isn't the right place to post about the Google > Summer of Code; if so, I would appreciate guidance toward the > correct list. > > If this is the correct list, I would appreciate answers to the > message below.This is the list, as is Damien's address, but I guess he has many emails to reply to. I'll try to answer, best as I can.> -----Original Message----- > I noticed your project idea regarding renovating sftp to improve > its command-line interface. Can you tell me more about this? For > this project, I assume you have certain key features in mind > besides recursive uploads/downloads via the command-line interface.I think this is about internal structure in the sftp client program. At present I view it more as proof of concept than an actual file transfer utility. That is what I would like the project to fix.> In addition, by "command-line interface", I assume you mean the > "sftp" command line and not the shell in which we enter when we > run sftp, correct?Naturally both those interfaces should be able to use any new features.> Also, I'm curious about the rationale for this. Why beef up sftp to > handle this if scp already takes care of it? Do you envision cases > in which scp is available but sftp is not?The sole reason for scp's existence is backwards compatibility with rcp. scp uses an application protocol similar (identical?) to rcp on top of Unix fd:s, and is really a sorry excuse for a file transfer program in 2009. scp does however work well enough for it to continue to be used by many, and in particular scp has some features which the OpenSSH sftp program lacks. SFTP on the other hand is a modern, standardized, file transfer protocol directly on top of SSH, and the sftp program is an elementary implementation of a client software. scp is bad, but can not be changed because it is compatibility only. scp is legacy. sftp (and to a degree SFTP, the protocol itself) can easily be changed and improved. Even the user interface can (and should) change, for the better. SFTP is the future. The OpenSSH sftp client is, as said, not so impressive, and it needs some love to really shine. The tool can be improved in many ways, internally and externally. Recursive transfers is just one thing. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090323/208111ad/attachment.bin
Quoth Peter Stuge> sftp (and to a degree SFTP, the protocol itself) can easily be changed > and improved. Even the user interface can (and should) change, for the > better. SFTP is the future. > > The OpenSSH sftp client is, as said, not so impressive, and it needs > some love to really shine. The tool can be improved in many ways, > internally and externally. Recursive transfers is just one thing. >Since SFTP appears to be on the RFC track, how does one go about proposing protocol extensions? In particular, an "append" command, similar to that of FTP?
On Mon, Mar 23, 2009 at 11:58:49 -0500, Peter Stuge wrote:> > sftp (and to a degree SFTP, the protocol itself) can easily be > changed and improved. Even the user interface can (and should) > change, for the better. SFTP is the future. > > The OpenSSH sftp client is, as said, not so impressive, and it needs > some love to really shine. The tool can be improved in many ways, > internally and externally. Recursive transfers is just one thing. >As long as improvements to sftp are being discussed, the addition of reget/reput support would be _very_ nice. I know the topic has come up on the mailing list a few times and there was at least one bug opened on this issue. But, unfortunately, it never seemed to get much traction. When dealing with large transfers (100GB+), the ability to resume an interupted transfer would be very handy. -- Iain Morgan