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

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

Good read, thanks. I am not sure how you can deal with blocking events (timer, 
read/write access to the disk). In that case, you are often "forced" to use 
"''a Lwt.t" function. For instance, in [1] when reading the Git pack file I 
need to pass a function to read uncompressed objects on disk (the read 
function) to support shallow objects (ie. objects whose ID is in the pack file, 
but whose contents is stored uncompressed on disk. And as usual, the Lwt.t 
propagates to the return type of that function...  I'm happy if you have a 
solution to this!

>> 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.  

The whole point is to have multiple instances of the functor in the same 
program. We want the ability to link multiple TCP/IP stacks (instantiated with 
different arguments) to create virtual networks for benchmarks or tests. 

The first iteration of MirageOS used only "linking tricks" and very few 
functors. It was working great until it wasn't, with no proper way to fix it. 
And the linking tricks started to look more and more like a pile of hacks. You 
can see the current approach (including functoria) as the way to 
programmatically do the linking trick. 

I completely agree that it causes some burden to the developers of libraries 
and adds complexity when you just want to use the library for a simple case 
(e.g. when you don't care about multiple instantiations). An other approach is 
to deal with this is the "big functor"[2] patch which was proposed a few years 
ago, but then you put complexity/logic in the build tools which don't really 
need this.  

Thomas

[1]: https://github.com/mirage/ocaml-git/blob/master/lib/pack.mli#L91-L97
[2]:  http://www.ocamlpro.com/blog/2011/08/10/ocaml-pack-functors.html
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel