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: Sat, 17 Mar 2012 09:46:48 +0800 Message-ID: References: <87zkbgeb6k.fsf@Kagami.home> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d042fd9409ab21604bb667fe2 X-Trace: dough.gmane.org 1331948826 23628 80.91.229.3 (17 Mar 2012 01:47:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Mar 2012 01:47:06 +0000 (UTC) Cc: guile-devel To: Daniel Hartwig , Ian Price Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Mar 17 02:47:05 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 1S8ijQ-0004KW-NM for guile-devel@m.gmane.org; Sat, 17 Mar 2012 02:46:56 +0100 Original-Received: from localhost ([::1]:43925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ijQ-0005D9-4o for guile-devel@m.gmane.org; Fri, 16 Mar 2012 21:46:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ijN-0005Ca-KC for guile-devel@gnu.org; Fri, 16 Mar 2012 21:46:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8ijL-0005mP-1N for guile-devel@gnu.org; Fri, 16 Mar 2012 21:46:53 -0400 Original-Received: from mail-vb0-f41.google.com ([209.85.212.41]:33569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ijK-0005m6-OA for guile-devel@gnu.org; Fri, 16 Mar 2012 21:46:50 -0400 Original-Received: by vbbey12 with SMTP id ey12so299455vbb.0 for ; Fri, 16 Mar 2012 18:46:48 -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=99aHOyalbAmWlUj7MzS/Ynu+nmwRUodkPhSC+3XAV8M=; b=VUveDMoTxPkc4rRG9L6PF5zLhkSdVFO/OZxXRXhw1PPYCTBi/rFQx2fPBAUE3oZBfS XATOBIEPKTGrkESTT2tsRBGxYO1wJ/xvecMXgcypX4TulM7fQ+ufdp5BbwWYrS4BtaKf v9hVgq6ItOWxikB/RvhN7A8EY5Jw89Ws6leRtSTGhnzqAblpPVVp/fDmMtQt4+uNonDV Dm5d8/mmjOjMDvFivyahl/+MM0YgDsXTRS7jzS1EsCG+iz7JTsA7s31466/Au7yEOVTt P5mgKZL/QRUPdhNs+PTaN4lSPj2ycXt6dY8fqppTDXh4aZCTQMOWwjHdXEiPV2wE0yn3 un6A== Original-Received: by 10.220.116.20 with SMTP id k20mr1346417vcq.54.1331948808745; Fri, 16 Mar 2012 18:46:48 -0700 (PDT) Original-Received: by 10.52.88.231 with HTTP; Fri, 16 Mar 2012 18:46:48 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.212.41 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:14133 Archived-At: --f46d042fd9409ab21604bb667fe2 Content-Type: text/plain; charset=UTF-8 Well, to clarify, I confess I did a wrong prejudging. I thought read-response-body is the only API to retrieve the body/data, so we should use it anyway to get the data rather than writing other procedure to handle it. Because the manual has only one API relate to this topic. But I was *wrong*. This read-response-body is just a simple procedure to get few body/data under easy circumstance. It is defined so. Anyone who needs a more complicated operation must write his own procedure with bytevector handlers or write a new http lib. So it's no need to change it's behavior with any patch. On Sat, Mar 17, 2012 at 1:25 AM, Daniel Hartwig wrote: > On 17 March 2012 00:57, Ian Price wrote: > > > > This still doesn't answer my concerns. I don't think the user should > > have to be checking the length of the result themselves. > > > > (let ((bv (get-bytevector-n (response-port r) nbytes))) > > (cond ((eof-object? bv) > > (incomplete-response ...)) > > ((= (bytevector-length bv) nbytes) bv) > > (else > > (incomplete-response ...)))) > > > > This. > > > Am I the only one who feels strongly about this? > > > > No. I guess you are still reading the rest of the thread ;-) > > --f46d042fd9409ab21604bb667fe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, to clarify, I confess I did a wrong prejudging. I thought read-respon= se-body is the only API to retrieve the body/data, so we should use it anyw= ay to get the data rather than writing other procedure to handle it. Becaus= e the manual has only one API relate to this topic.
But I was *wrong*. This read-response-body is just a simple procedure to ge= t few body/data under easy circumstance. It is defined so. Anyone who needs= a more complicated operation must write his own procedure with bytevector = handlers or write a new http lib. So it's no need to change it's be= havior with any patch.

On Sat, Mar 17, 2012 at 1:25 AM, Daniel Hart= wig <mandyke@gmai= l.com> wrote:
On 17 March 2012 00:57, Ian Price <ianprice90@googlemail.com> wrote:
>
> This still doesn't answer my concerns. I don't think the user = should
> have to be checking the length of the result themselves.
>
> (let ((bv (get-bytevector-n (response-port r) nbytes)))
> =C2=A0(cond ((eof-object? bv)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (incomplete-response ...))
> =C2=A0 =C2=A0 =C2=A0 =C2=A0((=3D (bytevector-length bv) nbytes) bv) > =C2=A0 =C2=A0 =C2=A0 =C2=A0(else
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (incomplete-response ...))))
>

This.

> Am I the only one who feels strongly about this?
>

No. =C2=A0I guess you are still reading the rest of the thread ;-)

--f46d042fd9409ab21604bb667fe2--