Re: new Cohttp interface progress

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 21 Aug 2012, at 07:29, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:

> 
> On 21 Aug 2012, at 15:18, Anil Madhavapeddy wrote:
> 
>> On 21 Aug 2012, at 07:01, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
>> wrote:
>> 
>>> i get that there are a number of different ways of implementing this, and 
>>> of designing the apis to be used; but i don't yet completely understand why 
>>> it's useful to abstract them all behind a single monad, and then allow the 
>>> programmer to choose their own implementation.  and i certainly don't see 
>>> that programmers are likely to be in a position to make an informed choice 
>>> based on the performance impact of the implementation selected without 
>>> going to a *lot* of work (possibly repeatedly).
>>> 
>>> though it does suggest, at least to me, that some sort of sensible 
>>> automated performance simulation/monitoring framework would make sense, and 
>>> would require a wrapping of this stuff in a monad of some kind. 
>> 
>> Purely for portability, and not tie the core parsing unnecessarily to one
>> of the (many) concurrency libraries out there.  One of the problems/features
>> of Lwt is that it affects all the types so much by using it, due to Lwt.t
>> going everywhere that could potentially block.  At this this way, it's a 
>> somewhat more abstract one that can be ported to Async's Deferred.t or be
>> replaced with a unit when it's not needed (i.e. if someone adds deferred
>> cothreading to OCaml directly).
> 
> ok, i buy the portability argument to some extent, though i thought that we 
> were trying to keep Lwt out of the core parsing libraries anyway, restricting 
> it to "polluting" just the server/client code itself?

Sure...and this way it's guaranteed to not pollute the core library due
to the functor preventing it.  I found a few places where Lwt-specific things
were used already. Also, all the cohttp forks existed for a reason: they were
all restructuring the same code, which is now hopefully more portable.

> having said all that, the discussion is rather moot if you've done it already 
> :)  certainly, there's nothing lost by having another layer of abstraction so 
> that the server and client code can abstract over the threading library.

Well, I'm wondering whether to apply this to the DNS code next (which is a
lot simpler, since most of it is non-Lwt parsing code).  I'd like to run
some more performance tests first, and prepare for the upcoming XenSummit
talk first though.

-anil