Re: FTP inside mc

[Thomas Kuiper <tkuiper t-online fr>]

On Fri, Dec 19, 2003 at 05:24:09PM -0500, Pavel Roskin wrote:
> On Fri, 19 Dec 2003, Thomas Kuiper wrote:
> 
> > Hello,
> >
> > I find the FTP interface of mc really useful and I'm willing to develop
> > an extension to it to support FTP profiles. Right now its only possible
> > to connect to a URL style address and its quite annoying to type or
> > search/remember some frequently used FTP sites.
> 
> >From the hints:
> Hint: Key frequently visited ftp sites in the hotlist: type C-\.
> 
> That should solve the problem with frequently visited sites.

Thats just a history like browsers offer them. It doesn't give you
the possibility to "bookmark" specific sites. 

> I don't quite understand the idea of profiles and whether you are going to
> use them for FTP connections only, or for fish and samba connections as
> well.

The point of profiles is that you can rapidly type the name of them
and browse existing profiles quickly instead of having to fiddle
around with the history which also includes all sites you visited
only for one time. Point is to make "mc" a good FTP Client. And every
FTP Client supports profiles or some bookmark system. mc already offers
everything a FTP Client basically need (two windows with local file system
in one and remote file system in the second one, etc.).

> Separate entries for host, username, password and remote directory -
> should be OK.  Those who want to enter the complete URL can do it on the
> command line.

I think for a enduser its much more clear. Don't expect anyone to understand
how URI's work. But of course the help of mc is very clear there. I don't
want to drop the ideas of URI's. They could continue to be working. 
Its not necessary to drop the simple "one line" FTP Link dialog. It could
it be set in the options if one prefers the simple FTP Link dialog.

> "Comment" - I have no idea what it means.  Maybe you want to create an
> alternative to the hotlist?  It was suggested many times, but every time
> it turned out that the author of the idea wasn't aware of the hotlist.

Comment is just a pointer for you what kind of site that is. People who
use FTP servers frequently or have mirror sites in it with just an IP for
example its nice to have a description what used the be behind this. You
can also store the same site many times with diffrent directories and with
long paths its easier to read the comment instead of searching in the long
path.

> "Use passive transfer" - good idea, but needs some work on the VFS side.
> The hotlist works with directory names, which are plain strings.  It
> doesn't save any hidden attributes, and rightly so.  There is currently no
> way to specify FTP options in the VFS path.  There is support for options
> in fish, which could be extended.

> In fact, the general syntax of VFS path is undocumented.  There is no way
> to use "@" in usernames, and there have been many complaints about it.

> I think we should start with "pen and paper" and agree on the syntax of
> VFS path, including options and ways to escape characters.  In case of
> smbfs, there should be a way to put the workgroup in the URL, so that VFS
> stops calling nontrivial user interface to request it.  Also, the
> alternate path notations such as ftp://... and rsh://... should be agreed
> on and documented.

True. It shouldn't be too hard to redesign the VFS Path a little bit to
make it possible for options or extensions. Not breaking it with too
many escape characters in the same time of course. There are some more
issues with passive FTP and its probably quite hard to implement 
but I just added it to the silly dialog I made cause I think
FTP Clients must have it :)

> "Don't store password in profile" - I still don't understand the idea of
> profiles.  If you agree on reusing the hotlist, we could think how to
> implement this.

Well the password with be asked each time. Check out TKFTP, or the popular
windows clients like CuteFTP, WsFTP and so on.

> Maybe the password should be saved in .netrc, the standard place for all
> FTP clients?  smbfs and fish would save passwords elsewhere, maybe in
> ~/.mc/fish_pass and ~/.mc/smbfs_pass respectively.

I'd prefer to store everything in ~/.mc/ftp-profiles so its easier to backup.

> >From the user point of view, it would be great if the password was asked
> for in the same dialog rather than separately, regardless of whether it's
> saved.  But from the security standpoint, it's better not to have the
> password as part of the VFS path. I tend to think that the user interface
> should not allow creating a path with the password.  However, the
> user:password syntax should be accepted if entered on the command line.

Sometimes people use security by obscurity. Which means they have FTP
logins like public/public or its just an account to push something in
/incoming where nobody cares if the password is "stolen".

> The existing code has some ad-hoc solutions for hiding the password from
> the path, but I think it's not the best solution.  It's easy to forget to
> strip the password.
> 
> To sum up, we should start with backend design before writing pretty
> interfaces.

Thats what I thought too and thats why I mailed here. Otherwise I would
just make it work for myself and send you a diff for your amusement :)

But I think its more nice if other peoples ideas are pleased and if it
gets in the original source tree :) I set myself a deadly to mid January
when I definetly start coding FTP Profiles into mc. Its my main concern
but in the end I may just end up on my own and provide some third party
supply for mc. Speaking of that mc could also have "module" support for
VFS things... but that sounds like work for a whole year until its
running completly... tell if you can't follow what I mean.

I'll see what other ideas come up here and will post my functional
specification what I will implement (considering but not implementing
necessarily all what was written in this list) in early January.

Now think :)
Thomas