From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] read-response-body should return received data when error occcurs (V2) Date: Fri, 16 Mar 2012 16:47:38 +0800 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec54fbd3ccbd70004bb5842a1 X-Trace: dough.gmane.org 1331888809 16552 80.91.229.3 (16 Mar 2012 09:06:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Mar 2012 09:06:49 +0000 (UTC) Cc: guile-devel To: Daniel Hartwig Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 16 10:06:49 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S8T7Y-0005gE-LZ for guile-devel@m.gmane.org; Fri, 16 Mar 2012 10:06:48 +0100 Original-Received: from localhost ([::1]:40805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8T7X-0004v2-Pu for guile-devel@m.gmane.org; Fri, 16 Mar 2012 05:06:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8T7T-0004uJ-6I for guile-devel@gnu.org; Fri, 16 Mar 2012 05:06:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8T7D-0004Qs-FO for guile-devel@gnu.org; Fri, 16 Mar 2012 05:06:42 -0400 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:56835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8Sp3-0001Kv-Uo for guile-devel@gnu.org; Fri, 16 Mar 2012 04:47:42 -0400 Original-Received: by lbbgf7 with SMTP id gf7so2377160lbb.0 for ; Fri, 16 Mar 2012 01:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FFTEutzmYW9s5RKyBYULp+9tetHZZC/SAiSIaKaqLng=; b=Xx1R38AQQbqIOU8KF/7a/nCTaXevqo7EpwR8KGXrjsSIrNA4AVhBSYOmkqK3JOtJ6G WFzv8W0Lv1Xwv2jmzt8+5tI3GrA6+STuILJggjfac8lvxq3ndhOuvhGjYEYTazME+HWE 6PehFj3IKKSMPBC1SH1m000yJa2EedIzJg4OyFcF9FuPyOkuRgua4w2rt0IGKP0/VFLv xfTWM3yP9DQqgUOB9nrQuFhRtKgZlnOBQ5qzxL5e4oiaDE0sfa571HUl0MlhL8P3dktj R4rMzHHE0NzVtrjWDxIxj+aEXx9XGmVMW/YPJj403Ns3apGHXzrqxJw8wuVrbNAWrWJP VBVA== Original-Received: by 10.152.108.171 with SMTP id hl11mr1239933lab.29.1331887659013; Fri, 16 Mar 2012 01:47:39 -0700 (PDT) Original-Received: by 10.112.28.169 with HTTP; Fri, 16 Mar 2012 01:47:38 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.217.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14120 Archived-At: --bcaec54fbd3ccbd70004bb5842a1 Content-Type: text/plain; charset=UTF-8 Well, I saw your point. So read-response-body is defined to read the whole body, and shouldn't return anything when it didn't get all the data. For this reason, one should use bytevector handler to get the data on one's own rather than read-response-body. Well, I just thought read-response-body is the only API to get body, at least from the manual, I can only get this conclusion. But in fact, the worth of read-response-body is very limited. It just a simple procedure to get a simple page or few data. If possible, I wish the manual can add few words to notice this. On Fri, Mar 16, 2012 at 3:32 PM, Daniel Hartwig wrote: > On 16 March 2012 13:54, Nala Ginrut wrote: > > This patch will return any data get-bytevector-n received and throw error > > when get . > > Actually, it's not the same feature in the old version thread > > http://lists.gnu.org/archive/html/guile-devel/2012-03/msg00116.html > > The old version is complicated because it catches *any* exception and > return > > the received data within exception. > > But this new version is an easy one. > > Yes, it looks much nicer :-) > > > My point is, read-response-body is a low level procedure, so we shouldn't > > make it complex. But our current doesn't return received data when > > the received data is less than the content-length. I think it should > return > > it, and let the user determine whether it's an error or continue > reading. > > So r-r-b is a really a two-liner: > > - read response body from port; > - make sure the complete response has been read. > > This combination is the utility of the procedure: it guarentees that > the data it returns comprises the complete response body. > > With your proposed change, that guarentee no longer holds. The caller > now must perform their own checks on the response data size, making > your function effectively this: > > - read response body data from port. > > So what is the utility of calling a procedure to do that over, say, > reading from the port directly? [pointed out earlier in this thread] > --bcaec54fbd3ccbd70004bb5842a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, I saw your point. So read-response-body is defined to read the whole = body, and shouldn't return anything when it didn't get all the data= .
For this reason, one should use bytevector handler to get the data on = one's own rather than read-response-body.
Well, I just thought read-response-body is the only API to get body, at lea= st from the manual, I can only get this conclusion. But in fact, the worth = of read-response-body is very limited. It just a simple procedure to get a = simple page or few data.
If possible, I wish the manual can add few words to notice this.

On Fri, Mar 16, 2012 at 3:32 PM, Daniel Hartwig <mandyke@gmail.com> wrote:
Yes, it looks much nicer :-)

> My point is, read-response-body is a low level procedure, so we should= n't
> make it complex. But our current doesn't return received data when=
> the received data is less than the content-length. I think it should r= eturn
> it, and let the user =C2=A0determine whether it's an error or cont= inue reading.

So r-r-b is a really a two-liner:

- read response body from port;
- make sure the complete response has been read.

This combination is the utility of the procedure: it guarentees that
the data it returns comprises the complete response body.

With your proposed change, that guarentee no longer holds. =C2=A0The caller=
now must perform their own checks on the response data size, making
your function effectively this:

- read response body data from port.

So what is the utility of calling a procedure to do that over, say,
reading from the port directly? [pointed out earlier in this thread]

--bcaec54fbd3ccbd70004bb5842a1--