Re: [MirageOS-devel] How to implement protocols?

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

> On 13 Nov 2015, at 15:43, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> 
> Le vendredi, 13 novembre 2015 Ã 15:22, Hannes Mehnert a Ãcrit :
>> I personally find the cohttp and TCP/IP code hard to read due to the use
>> of lots of functors / module abstractions, which are not necessarily
>> needed IMHO.
> 
> Not only they are not needed, it's also the wrong way of handling this as it 
> is well known that factoring out module dependencies as functors doesn't 
> scale in practice. The question to ask yourself for using a functor is: do I 
> need multiple instances of the functor in *the same program* â good examples: 
> {Map,Set}.Make.
> 
> See http://www.cis.upenn.edu/~bcpierce/papers/modules-icfp.ps for more on 
> this. 

One of the design goals of Cohttp was to allow multiple, completely independent 
network stacks (including sockets and direct stacks) to run within the same 
program.  It has also been fairly successful at getting third parties to port 
the appropriate part of the interface that they need to different backends, 
such as Andy Ray doing a JavaScript version that uses only the higher-level 
parts of the stack.

It's also worth noting that you can even use Cohttp_async and Cohttp_lwt within 
the same program, as Jeremie Diminio did an Lwt-on-Async adapter.  This isn't 
necessarily advisable, but it is possible :-)  Again, this will all be 
consolidated when we have a more standard concurrency story within OCaml, but 
functorising IO wasn't an entirely terrible decision.

Where functors fall over is the terrible documentation and tooling assistance 
when faced with using one, and this is being addressed by codoc and Merlin.

> Other than that the document feels like unstructured, poorly written [1], 
> random rumblings. 

Grumpy day, eh?  I thought it was an excellent first cut that laid out some of 
the issues to consider for beginners wishing to build their own protocol.  We 
can iterate on it, which is Hannes' intention for sending it to this list.

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel