The HAppS HTTP code basically delivers the first 64k and a handle to
acquire the rest. The 99% or higher case is that the document fits in
memory so the 64k bound is fine. If you have something bigger, the
user is going to have to decide how to handle that on a case by case basis.
Note:
On Thu, May 24, 2007 at 10:17:49PM +0100, Jules Bean wrote:
I've been having something of a discussion on #haskell about this but
I had to go off-line and, in any case, it's a complicated issue, and I
may be able to be more clear in an email.
The key point under discussion was what kind of
Hello Jules,
Friday, May 25, 2007, 1:17:49 AM, you wrote:
The key point under discussion was what kind of interface the HTTP
library should expose: synchronous, asynchronous? Lazy, strict?
isn't it possible to implement simplest (strict sync) interface as
base and then add higher levels if
I've been having something of a discussion on #haskell about this but
I had to go off-line and, in any case, it's a complicated issue, and I
may be able to be more clear in an email.
The key point under discussion was what kind of interface the HTTP
library should expose: synchronous,
Hello Cafe!
I'd greatly appreciate any ideas/comments on the design of the
interface to the Network.HTTP library with a LazyByteString (LBS)
backend.
As has been discussed previously on this list [1] lazy evaluation can
complicate resource management, which is especially critical if
resources
I am uncertain about all the issues here, but
Why do you need to convert Socket to Handle?
I have no clue if this code I pasted below works but it does compile:
import Network.Socket
import Data.ByteString.Base as Base
-- 'recvBSFrom' gets a strict ByteString from a socket.
--
On 5/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Why do you need to convert Socket to Handle?
Initially, we chose to use socketToHandle for simplicity reasons--why
duplicate functionality if we can reuse it? After Simon Marlow's
comment that my reason to assume it inappropriate does no
