Linda W wrote:
Might it not be "useful" if Net::FTP could use an ftp_proxy, transparently,
if one was set in the environment?
Net::FTP couldn't provide its entire API if proxied; after all, the proxy
is pretty-printing the directories into HTML so they look nice in a browser.
Just ask the authors of NcFTP why they don't support HTTP proxies :).
Note that LWP::UserAgent can fetch FTP URLs transparently using whatever
environment proxies are defined, if any. If you're using an FTP server as
if it were an HTTP server, it makes sense to use an HTTP interface.
Than again, maybe the author will disagree with me and add the feature,
who knows :).
Unlike most people in the linux world, I don't think the concept of
a single per-user/per system registry would be a bad thing if done
right -- all the little config files/rc files sitting around on volumes
with large allocation block sizes and wasting a large amount of
filespace... If done "right", could make moving setups between systems
easier...
You'll hurt your head thinking about that for too long. The technical
inefficiency really isn't the issue at all, and in fact if you're on a
real OS then it isn't even inefficient.
UNIX does have a registry. It's called /etc and ~/.*, the problem is
that after 30+ years of text file config formats, we've decided we still
love text files but we don't like the differences in their format. If
you want to ease the standardisation of these things then just use YAML
for your next config format, and be done with it. If YAML were to become
best practice for a configuration file format, you could present them
with an API that looked like a registry anyway. The idiosynchronacies
would still be there but the solutions should proliferate.
Such a change will take a long time to get right, I think most people
will agree that many of the benefits arising from a convention regarding
making configuration files homogenous in a way that is almost, but not
entirely, quite unlike a registry is probably worth it in the long run
- but it will be a slow, slow process.
Maybe if you write a nice generic cross-platform GUI YAML config editor
for YAML dotfiles that applications can provide custom extension dialogs
for, then you will have something control-panel like for conforming
applications. The idea is that it's trivial for application authors to
supply the information used to build the GUIs, and possibly even plug
their own components in.
Actually, such an idea would naturally need to have alternate UI support,
a bit like Debconf I guess - but be warned, and people who call this
flamebait can be damned - Joey Hess' code is not to be taken as a good
example for style. Seeing main loops like this;
1 while $debconf->communicate();
Make me want to shoot the author on grounds of inapproprate public
displays of self-affection. Besides, debconf is combined in unholy
matrimony with the system packager, and focuses on a different set of
goals.
And whatever you do, don't call it a registry, you'll hit a sore spot on
lots of people ;)
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
