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

Bruce Blackshaw <bblackshaw@gmail.com> Sun, 27 January 2013 23:52 UTC

Return-Path: <bblackshaw@gmail.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 1E1DF21F84CA for <ftpext@ietfa.amsl.com>; Sun, 27 Jan 2013 15:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ZDPYArAmQ1rq for <ftpext@ietfa.amsl.com>; Sun, 27 Jan 2013 15:52:21 -0800 (PST)
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4145121F841D for <ftpext@ietf.org>; Sun, 27 Jan 2013 15:52:15 -0800 (PST)
Received: by mail-pa0-f53.google.com with SMTP id hz1so1168776pad.26 for <ftpext@ietf.org>; Sun, 27 Jan 2013 15:52:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:reply-to:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zlsKLHtG3eoIx71+IH+07MT2QTsh8eN+jhJpi9yrMsI=; b=ruNw6+431VCji4vvMrtRlC7t4ayBex7cELvmYOoZUyZnBxss/psHz0EKOxuzjM9dV6 ehJ0uD4uDvOR/GrfGZuTcL7Gf1h7dU6vx2Iim0i0TMkbRzK0Yfr2v+eVfqva5XoWeJC9 q8zpAfYFtdl5y4smGIvNhNs2pVq1j8Mx+EDoi/JnL4geR2UBu7fgqqjZcy3ef7AMqVMP 0qr1Zjk6TtKrIZLQsNfOxxc3e/jLZoRVUH5Sj4Gk1ihX5CCW/4flf83NVcofg95lQBaO +bVi9YdDftLnTppqpKBi1BCrZGfI/dRVRk+u+EuSX3E4ZM9wD6vAxAv2gQ0my8XtZZdo CrIA==
X-Received: by 10.66.82.103 with SMTP id h7mr16570722pay.6.1359330735082; Sun, 27 Jan 2013 15:52:15 -0800 (PST)
Received: from [192.168.1.4] (ppp167-208-56.static.internode.on.net. [59.167.208.56]) by mx.google.com with ESMTPS id vq4sm5090801pbc.67.2013.01.27.15.52.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 15:52:13 -0800 (PST)
Message-ID: <5105BDA8.7000006@gmail.com>
Date: Mon, 28 Jan 2013 09:52:08 +1000
From: Bruce Blackshaw <bblackshaw@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Alun Jones <alun@texis.com>, ftpext@ietf.org
References: <CANqTPegPaMBF9i1gi+M3m5FXzuxRzUU_QULxB_sdJTVd7NGppQ@mail.gmail.com> <51009243.4080809@gmail.com> <51056391.2070901@gmail.com> <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com>
In-Reply-To: <03ec01cdfcbc$b247bef0$16d73cd0$@texis.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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
Reply-To: bblackshaw@gmail.com
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 23:52:22 -0000

It's true that you don't always know the size at the start.

Nonetheless, it could be be specified that iff the size of the raw data 
is known, then "size" could be used. In the many cases that this is 
possible, performance should be faster (although I can't quantify by how 
much).

regards

Bruce Blackshaw

On 28/01/2013 4:32 AM, Alun Jones wrote:
>> 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.
> ~~~~
>
>