From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.76.94.227 with SMTP id df3csp86041oab; Thu, 22 May 2014 14:12:13 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBCPP5HNTQUDRBK6Q7GNQKGQEBVVS24A@googlegroups.com designates 10.140.109.199 as permitted sender) client-ip=10.140.109.199 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBCPP5HNTQUDRBK6Q7GNQKGQEBVVS24A@googlegroups.com designates 10.140.109.199 as permitted sender) smtp.mail=rack-devel+bncBCPP5HNTQUDRBK6Q7GNQKGQEBVVS24A@googlegroups.com; dkim=pass header.i=@googlegroups.com X-Received: from mr.google.com ([10.140.109.199]) by 10.140.109.199 with SMTP id l65mr65896qgf.32.1400793132701 (num_hops = 1); Thu, 22 May 2014 14:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:sender:list-subscribe:list-unsubscribe:content-type; bh=DpuXTJB6S4ZO4VXDyMXCTnRL1orWDzj1ctPx7LjOmmA=; b=Qrp+xIl8JzNsmmMOzC+aCw7T7CFp1iJI4L7dun0sII5XYuHMnd+MeHUCIptm3DTzne QwdMC+JnwSMBcRrF3AHVu7K6F7vUrVSlH9UkvOI6wZiDtNcSDadlqzR6S9hLDYn4Pok7 ClagSeunyjAC9LAMX/CLhf0QvM7pba4brxE2exOZJz+Jb2h+8UFBWq7IjdJzFfAeUC9N VI+YlgNxRE9KezkCOd3lnVvHWhvX6j87G9rwTsF4AKdfvcY+n8iorkKwHrKsjWxb2gZH EP09fhvHUS0eSJINOHlSjtoMGwv3SemKIAe8JVHPUriVxTJJVSRqGAX+OqKPwH+96GKd 3lUw== X-Received: by 10.140.109.199 with SMTP id l65mr5046qgf.32.1400793132563; Thu, 22 May 2014 14:12:12 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.140.82.37 with SMTP id g34ls1469912qgd.64.gmail; Thu, 22 May 2014 14:12:11 -0700 (PDT) X-Received: by 10.140.92.227 with SMTP id b90mr3906qge.25.1400793131744; Thu, 22 May 2014 14:12:11 -0700 (PDT) Date: Thu, 22 May 2014 14:12:09 -0700 (PDT) From: Torsten Robitzki To: rack-devel@googlegroups.com Message-Id: Subject: rational for rewind() MIME-Version: 1.0 X-Original-Sender: torsten@robitzki.de Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary="----=_Part_15_14767994.1400793129626" ------=_Part_15_14767994.1400793129626 Content-Type: text/plain; charset=UTF-8 Hello, I'm implementing a C++ comet web server, that (tries) to implement rack to adapt ruby applications. Currently I'm reading a body very naively put the body into a ruby String and wrap it with a StringIO to provide the rack.input for the implementation. As I'm going to use the server for uploading images, I would like to implement a real, stream-like object to circumvent the need to buffer the POST body before handing it to the application. Now, I've read the rack specs and read about rewind(). To implement rewind(), I would have to store the whole body, even when the upstream application just calculates some kind of checksum on the body, or uploads it to s3. What's the rational behind this part of the specification? Is it possible to not implement rewind() and to tell applications that need rewind(), to keep there own copy of the body, in case it is needed? kind regards, Torsten -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ------=_Part_15_14767994.1400793129626 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
I'm implementing a C++ comet web ser= ver, that (tries) to implement rack to adapt ruby applications. Currently I= 'm reading a body very naively put the body into a ruby String and wrap it = with a StringIO to provide the rack.input for the implementation. As I'm go= ing to use the server for uploading images, I would like to implement a rea= l, stream-like object to circumvent the need to buffer the POST body before= handing it to the application.

Now, I've read the= rack specs and read about rewind(). To implement rewind(), I would have to= store the whole body, even when the upstream application just calculates s= ome kind of checksum on the body, or uploads it to s3. What's the rational = behind this part of the specification? Is it possible to not implement rewi= nd() and to tell applications that need rewind(), to keep there own copy of= the body, in case it is needed? 

kind regard= s,
Torsten

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
------=_Part_15_14767994.1400793129626--