Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST

"Alun Jones" <alun@texis.com> Sun, 27 January 2013 18:32 UTC

Return-Path: <alun@texis.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB0D21F84D1 for <ftpext@ietfa.amsl.com>; Sun, 27 Jan 2013 10:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.81
X-Spam-Level:
X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfJ2EblEcey4 for <ftpext@ietfa.amsl.com>; Sun, 27 Jan 2013 10:32:44 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2321F84C8 for <ftpext@ietf.org>; Sun, 27 Jan 2013 10:32:44 -0800 (PST)
Received: from rocksolid (c-24-19-33-75.hsd1.wa.comcast.net [24.19.33.75]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MKYYR-1Tyi5P1Y6J-001ZWc; Sun, 27 Jan 2013 13:32:44 -0500
From: Alun Jones <alun@texis.com>
To: 'Ángel González' <keisial@gmail.com>, bblackshaw@gmail.com
References: <CANqTPegPaMBF9i1gi+M3m5FXzuxRzUU_QULxB_sdJTVd7NGppQ@mail.gmail.com> <51009243.4080809@gmail.com> <51056391.2070901@gmail.com>
In-Reply-To: <51056391.2070901@gmail.com>
Date: Sun, 27 Jan 2013 10:32:39 -0800
Organization: Texas Imperial Software
Message-ID: <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQIt3E4NnXG8QPMl9Ih5faZkLyE7NwIU5rYDAdN4gr6Xfnz/oA==
X-Provags-ID: V02:K0:Oj32U6XrwD3XOdHvX/x8eZf8ODL6fB9xK2nM0zT+EKw EOS6F7u9FWdnWcSiV5g+ofc1u658b6Kp0HgLXZXN2KJB4kHNsX RHJYY6hDG8GhaiPNraE/F5mXYAbLF/aagbkIf/9Yvhc+HhNM40 xn4qdSRwkgc4BEomDvvt+WqJ3L0QADfpcunUVWNKW89g9XQVNH 7Wmr/b8gFXBnVl5/x+TdFNCpJo8R3YUY74NPFIjpvlpGzup/lU xkNKvGxJfz2yYwLKxRx08cjZYzmvC9MQOUHl5ozpm9Jwkl8NHU cyksanZ4/wqtP18ZhRUzol0qSHNueJqaCMkV2RpB+x6lOeB5Jo XEd8HfKY4b/2NFtLaSvo=
Cc: ftpext@ietf.org
Subject: Re: [ftpext] New Version of FTP HASH, RANG, LOCK, and HOST
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Jan 2013 18:32:45 -0000

> Of Ángel González
> 
> Bruce Blackshaw wrote:
> > Re LOCK, I think it would be useful to have an alternative to
> > "boundary" called "size", that could provide the size of the raw data
> > for binary transfers.  That might provide quite a performance
> > advantage compared to having to search for the boundary.
> >
> > regards
> 
> Good point. I think it would be much more useful than the boundary
> method.
> The value of such size parameter should be the amount of data sent on the
> wire.

This has an obvious problem - what if the size of the file changes during
the transfer?

There are many uses of FTP (webcam being the one that comes immediately to
mind) where a "file" is retrieved, and is handled as if it is a
potentially-infinite stream. We have a webcam at work that encodes video as
an animated GIF that never ends. Doesn't display in Internet Explorer,
because IE is paranoid, but it's a use-case that should be considered. The
boundary method works for this use, where the size method doesn't.

Alun.
~~~~