You disagree with what? I thought I was quite clear that the appropriate meaning of SFTP is SSH File Transfer Protocol and has been for years. I certainly didn't think I was arguing that people ought to use it to mean anything else.
Many users (and a few clients and servers) do use the term incorrectly. I don't like it, and clearly you don't either...I don't see what you're disagreeing with.
And, of course FTP over SSL is not extremely rare...not even close to rare. All of the major FTP servers, and many FTP clients, support it quite easily, and many, many end users insist on it. ProFTPd, possibly the most popular FTP server, can be configured to use it with just a few configuration directives.
I'm not encouraging anyone to use the terms incorrectly or to use the FTPS protocol instead of SFTP. In fact, I've been recommending SSH FTP for years (one could probably dig up mailing lists posts that include me scolding people for using FTP from ten years ago).
I guess I've not been very clear. I apologize for misleading anyone into thinking I intended to praise the misuse of terms. I just wanted to point out that people use the terms incorrectly extremely often, and it's wise to be explicit about the protocol you mean.
You asked what I specifically disagreed with. Your original post:
> the most common meaning of SFTP has come to be "FTP encrypted with SSL"
I disagree with that. We both think people should use 'SFTP' to correctly mean as implemented by an SSH server, but you think the term has lost meaning. I am disagreeing with that.
OK. I'll buy that, and based on a search of the various terms, things seem to be improving. My personal experience is clouded by supporting our own products, which is possibly not an entirely representative sample. But, for what it's worth, we have about 1000 paying customers who are web developers...and we're still hearing misuse of the terms on a very regular basis. I'd like to think things are getting better.
Joe, while I've got your attention, somewhat off-topic, does webmin use an intermediary language that spans all config files, or does it directly parse for each format?
Independent parser for every config file. It's the only way to do it such that it allows you to edit config files outside of Webmin, using the command line, using other tools, etc. and have it respect those changes, along with comments and file order. I've used dozens of management products over the years that start from a database and push out the config files via templates, and other such "One True Vision" kind of thing, and it's just not worth it. I can see a few places where it makes sense...for example, I see a place in the world for tools like puppet. But I've never been in a situation where I was willing to accept a GUI or management automation tool as the only way to ever edit a configuration file (though, with Webmin, I almost never need to hit the command line, I always can).
Webmin is written in Perl, and it uses a few relatively simple libraries that Jamie has built over the years (Webmin is 11 years old this October) for slurping files into arrays, breaking them into key=values, etc. Thus each module has a lot of code devoted to parsing...some more than others. We've begun working on making this functionality accessible to other Perl code (and eventually other code in general) via APIs, but that's still coming along slowly...and some of it is unfortunately not abstract enough to be as useful as we'd like. For example, using the Postfix module and the Sendmail module doesn't necessarily have the same semantics--starting and stopping the service are almost always the same between services, but anything config file related is very specific and you have to have knowledge of the directives to do anything with them.
Sometimes the parsers use regexes, sometimes array munging with splice/unsplice/push/pop/etc. grep and map play a big role in Webmin code as well, as they make a lot of kinds of parsing a lot more concise. The code can be intimidating at first, as it's really big (~400kLOC), and because Webmin has never (intentionally) broken backward compatibility for module authors (in eleven years!) has a lot of pretty hairy legacy code. Newer modules and those that are more aggressively maintained (Dovecot, Virtualmin and its related modules, Sendmail, Postfix, Apache, etc.) are nicer to read than older ones.
Anyway, I don't think there is any one silver bullet to deal with configuration files on Linux. They're all pretty wildly different, and some have very bizarre quirks and complexity. Apache, for example, can have arbitrary directives and syntax added by modules, and anything that parses the configuration has to be able to at least understand it well enough to skip over those sections and directives.
Thanks for your thoughts - the various incompatible config file formats is something I've been pondering over for some time, and it's interesting to hear the thoughts of someone with experience.
I wonder about suggesting a common format capable of storing most config file structures as an RFC, then patching those apps to optionally use the format. If you could get Samba, BIND and Postfix the rest could follow...
It's a problem of momentum, and everybody having different ideas about what the right configuration file syntax should be.
One could make the case for something like "everybody use ini syntax", which is the Samba config file format, and the default configuration file format for Python's ConfigParser module (and most other languages have good parsers/writers including Perl). I think it has some concept of nested sections, but I'm not sure it could handle the complexity of BIND or Apache without difficulty. An Apache VirtualHost section can have many sections within, including non-unique sections (e.g. multiple Directory sections), and quite a lot of other tricky stuff, and I'm not able to think of an intuitive way to represent that in ini. I wrote an ad-injecting redirecter for Squid in the distant past that used ini format files...and I ended up having many files in a directory, because it needed nested data. My point is that there's a reason the Apache config file is as complex, and different from everything else, as it is...because it would be hard to convince simpler formats to express all of the information concisely.
Pretty much any config file format can be convinced to do just about anything, though--I'm often stunned at the whacked out crazy crap Jamie does with the Webmin configuration files, which are key=value files. He's got Perl code hiding in some of the values, for example--ternary operators and such--which gets evaluated into place as needed (this is much safer than it sounds). So, whatever format someone came up with would end up being extended as needed and that means you'd have to accomodate all of those extensions--but it still might be nicer for the folks building management tools to have at least a basic standard, even if the management tools don't necessarily know what all of the sections/directives mean.
That said, I suspect that if one could convince a standards body to get behind a "standard" config file format, you'd end up with some XML creature that no one would be happy with, not even those of us who have to parse the configuration files and would ostensibly be relieved to only have one file format for everything.
Momentum is also a problem. I don't foresee anyone on the Apache project, thinking, "Hey! Let's add a second config file parser so people can use SCFF (Standard Config File Format) so Apache configuration files will be the same as a couple of other projects!" It'd be more likely that one or two small projects would use it, and nothing much would change...we'd just have one more configuration file format to parse to support those couple of packages.
Jamie has a sort of funny, and deeply pragmatic, attitude about the whole thing: If it works, why break it? He hates it when anything changes, even to get simpler. New directives to old configuration files. Incompatible changes, even if they are simpler to parse. Etc. So, he'd probably be more angered than pleased to learn that everyone is going to change to some "universal" format.
Now that we're talking about it, I'll mention that Postfix has one of the best configuration systems I've ever seen. key=value main.cf, one-line arrays in master.cf, and space-delimited map files for all of the aliases, virtual domains, transport maps, etc. It takes a lot of files, but it's really easy to parse in just about any language, and I find it really easy to use as a human, as well. And, the kicker is that it's three file formats...so a single config file format wouldn't even work for the single Postfix service!
Many users (and a few clients and servers) do use the term incorrectly. I don't like it, and clearly you don't either...I don't see what you're disagreeing with.
And, of course FTP over SSL is not extremely rare...not even close to rare. All of the major FTP servers, and many FTP clients, support it quite easily, and many, many end users insist on it. ProFTPd, possibly the most popular FTP server, can be configured to use it with just a few configuration directives.
I'm not encouraging anyone to use the terms incorrectly or to use the FTPS protocol instead of SFTP. In fact, I've been recommending SSH FTP for years (one could probably dig up mailing lists posts that include me scolding people for using FTP from ten years ago).
I guess I've not been very clear. I apologize for misleading anyone into thinking I intended to praise the misuse of terms. I just wanted to point out that people use the terms incorrectly extremely often, and it's wise to be explicit about the protocol you mean.