Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

["Mark P. Peterson" <[e-mail]>]

Hi Daniel,

Thank you for your response and your comments.  The reason they're called
"streamlined" is because 4 out of the 5 commands could be performed via
other methods, these allow them to be performed in a single command.

Mark P. Peterson - President
http://www.RhinoSoft.com
Voice: [phone]
FAX: [phone]


--------------------------------------------------
From: "Daniel Stenberg" <[e-mail]>
Sent: Thursday, December 02, 2010 5:17 AM
To: "Mark P. Peterson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

On Tue, 16 Nov 2010, Mark P. Peterson wrote:

> I just wanted to mention that my document,
> "draft-peterson-streamlined-ftp-command-extensions" is alive and I would
> like it to remain in consideration within this discussion and the charter.
> Could we get some feedback regarding its priority and content.

Hi Mark,

I've been away, but here are my comments to the draft:

o The name "Streamlined FTP Command Extensions" reads very odd in my mind, as
   they are in fact new/additional commands, I don't see how they streamline
   anything.

o RMDA - I think a 'rm -rf' version is a very good addition to FTP and it is
   in fact a generally requested operation by users in my experience.

o DSIZ - I see very little value for DSIZ in practise. Since the size of a
   given number of files is only true in that very instant, the returned value
   will just be a reason for misunderstandings and misuse. The way the command
   is described is however accurate and functional.

o AVBL - I see very little value for AVBL in practise. First off, this is
   only true the very moment the command is invoked and the next moment
   there may no longer be anything at all left so using the value for any logic
   will almost certainly be done wrongly. Further, disk space availibility
   depends on a lot of other factors as well besides just "available octets",
   så if there us 1000 bytes free you may be able to store a single 1000 byte
   file there, but perhaps not even be able to store 5 100 byte files. Alas,
   the value of such a command is questionable to me.

o THMB - I am firmly against this command. The idea that we would
   promote a command that makes a thumbnail for an image file is an abonimation
   in my mind. That's not the job of FTP, the "File Transfer Protocol". If you
   need thumbnails for whatever file format, then provide them either directly
   as plain files in your file system, or write an FTP server that provides
   "virtual" files that you generate on demand when the client asks for the
   files. I strongly oppose this command.

o CSID - fine with me. I don't see much benefit for many vendors to
   immediately start supporting it, but I don't see any harm in making a
   standard way to get/expose the information.

-- 

  / daniel.haxx.se