On 1/17/2009 08:21, Tim Newsham wrote:
There's however still no framework which supports both HTTP client and
server functions using the same Request and Response data type, right? I
don't know whether I am the only one who needs this (e.g. for the Real
Monad Transformer). E.g. a proxy would
On Sat, 2009-01-17 at 20:34 -1000, Tim Newsham wrote:
Speaking of proxies, I've been looking into how to find the right proxy
to use on Windows systems. Turns out that to do it properly you need a
JavaScript interpreter! Yes, really.
Uhh.. What!? That's not right.
I think you mean it
There's however still no framework which supports both HTTP client and
server functions using the same Request and Response data type, right? I
don't know whether I am the only one who needs this (e.g. for the Real
Monad Transformer). E.g. a proxy would need this, too.
I've wanted this for a
On Fri, 2009-01-16 at 17:57 +0300, Bulat Ziganshin wrote:
Hello Sigbjorn,
Friday, January 16, 2009, 5:42:06 PM, you wrote:
first question: are these packages (http, curl, curl-shell, webclient)
windows-compatible? second - that is advantages of using http (or
webclient) over curl?
I
Hi Sigbjorn,
On Thu, Jan 15, 2009 at 10:36:35PM -0800, Sigbjorn Finne wrote:
I've yet to gain access to www.haskell.org and update
http://www.haskell.org/http,
Perhaps this would be a good point to move the website to the community
server?
Thanks
Ian
On Thu, 15 Jan 2009, Sigbjorn Finne wrote:
I guess it's time to publish more widely the availability of a
modernization of the venerable and trusted HTTP package, which I've been
working on offon for a while.
I was always afraid that a fork may happen during I work on HTTP in order
to get
Just as a reported speedup, downloading a 5MB file from my own local
machine (via http) went from 1.05 secs to 0.053 secs. Yes, it's
really an order of magnitude better. Performance now is on par or
slightly better than cURL (however to get more protocols than HTTP,
you'll still need the
On Thu, 2009-01-15 at 22:36 -0800, Sigbjorn Finne wrote:
Another change/fix in this release is the _alleged_ fix to the
long-standing bug in the use of absolute URIs vs absolute paths in
requests (for non-proxied and proxied use.) Give it a go..
cabal-install with HTTP-3001.x:
$ cabal
Thanks Jeff,
regarding having to use both HTTP and cURL -- or perhaps only
the latter for code simplicitly -- that will probably remain the case for
quite a while still. To help with that situation, I put together an
over-arching
'webclient' library that abstracts over the transport layers
Hello Sigbjorn,
Friday, January 16, 2009, 5:42:06 PM, you wrote:
first question: are these packages (http, curl, curl-shell, webclient)
windows-compatible? second - that is advantages of using http (or
webclient) over curl?
sorry if questions are stupid - i'm pretty ignorant here :)
Thanks
On Fri, 16 Jan 2009, Sigbjorn Finne wrote:
gain access to www.haskell.org and update http://www.haskell.org/http,
so for now you may pick up a new version the lib via
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTTP
GIT repo for HTTP-4000 / HTTPbis is here
On Thu, 15 Jan 2009, Sigbjorn Finne wrote:
I guess it's time to publish more widely the availability of a
modernization of the venerable and trusted HTTP package, which I've been
working on offon for a while.
Bunch of changes, but the headline new feature of this new version is
the
lemming:
On Thu, 15 Jan 2009, Sigbjorn Finne wrote:
I guess it's time to publish more widely the availability of a
modernization of the venerable and trusted HTTP package, which I've been
working on offon for a while.
I was always afraid that a fork may happen during I work on HTTP
Yes, please do. At some point soon, I will do and release a feature
and performance benchmark on HTTP-3xxx, -4xxx, -lazy (if you release
it), and cURL, that way people can use what's best for their
application.
On Fri, Jan 16, 2009 at 12:29 PM, Don Stewart d...@galois.com wrote:
lemming:
On
Sounds very good to me. However I would like to as one question
regarding the HTTP lib. On hackage I read: HTTP: A library for
client-side HTTP. Maybe you or someone on this list can tell me what
the restrictions of the HTTP library are that restrict it to client
side. What would be required to
Hi Levi,
I'm guessing that you are reading something different into that
than what's intended - it's client-side in the sense that it can
only issue web requests and handle their responses. i.e., it
doesn't handle incoming HTTP requests and issue suitable
responses. Web server implementation is
Sigbjorn Finne schrieb:
Hi Levi,
I'm guessing that you are reading something different into that
than what's intended - it's client-side in the sense that it can
only issue web requests and handle their responses. i.e., it
doesn't handle incoming HTTP requests and issue suitable
Don Stewart schrieb:
lemming:
On Thu, 15 Jan 2009, Sigbjorn Finne wrote:
I guess it's time to publish more widely the availability of a
modernization of the venerable and trusted HTTP package, which I've been
working on offon for a while.
I was always afraid that a fork may happen during
On Fri, Jan 16, 2009 at 8:11 PM, Sigbjorn Finne
sigbjorn.fi...@gmail.com wrote:
I'm guessing that you are reading something different into that
than what's intended - it's client-side in the sense that it can
only issue web requests and handle their responses. i.e., it
doesn't handle incoming
Hi,
I guess it's time to publish more widely the availability of a
modernization of
the venerable and trusted HTTP package, which I've been working on
offon for a while.
Bunch of changes, but the headline new feature of this new version
is the parameterization of the representation of
20 matches
Mail list logo
