The point of your original post seemed to be that this
would make it somehow easier to update a site. Does it? Let's
go through the steps for each.
Your way (if I understand you correctly)
- Start up mini-ftp server
- Open big-honking browser that can handle multipart encoding
- Go to URL with file input field
- click browse, navigate, and select ortype the filename
- click go (or have it upload onChange or something equally silly)
- Shut down mini-ftp server
Using ftp from command line
- change to directory where file resides
- ftp to your server
- Enter username, password
- put file
- quit
Frankly I don't see a great deal of time saved or a huge
improvement in useability. Although it is clever, it seems
like it might just be easier and quicker to ftp (or sftp,
or scp). And although the risk is slight from a security stand
point, it does make me curious whether you've ever forgot to
turn out the lights.
| [reply] |
Oh, and I almost forgot the most important: my machine at work is NOT registered in the DNS, so it is totally impossible to ftp to my university, because the servers there check for DNS registration.
So... when FTP is completely unavailable, the purpose is more obvious!!!
| [reply] |
Well, I'm sorry, but no. I have to disagree with that.
First, you have to remember that this file input field is integrated in the update form along with the other update input (text fields), making it a unique updating application to use.
Now, if you don't have my "live" update CGI, you have to use on top of that the ftp transfer, which, as you describe it, has several steps. For the little server, there is only one click to launch it, and one click to kill it.
Speedwise, I'm telling you, the file transfer is faster than ftp.
Turning the lights off? You won't forget that since there is an application running that takes room on your desktop.
And again, there is no unencrypted password transfered, especially the one of your whole unix account: Security is better than ftp.
BTW, there is no need for multipart encoding to use a textfield. I am not using CGI.pm, I have no need for it.
| [reply] |
Why did you even post your idea here for peer review if you
are going to go defensive everytime someone points at a
potential flaw in your plan?
Some very valid, and note-worthy ideas have been voiced.
Here is the only circumstance when you should use your method,
in my opinion:
- Unable to ftp to web server machine, whether by name or IP.
- Unable to open ftp up on a higher order port (not good idea).
- Unable to email the file to your webserver (don't you have shell access?)
- Unable to ftp out of the web server (shell access, again?)
- NO OTHER MEANS OF TRANSFERRING FILES IS AVAILABLE
I know that I, for one, would like to know the exact
environment where you believe this is warranted.
Don't get me wrong, it is a cool means to do something,
if no other method is available.
J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/
| [reply] |