Re: [MirageOS-devel] Dispatching boilerplate and the tutorial

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

On 16 July 2015 at 19:25, Drup <drupyog+caml@xxxxxxxx> wrote:
> The mirage guide presents nice and simple unikernels in the first
> tutorial[1], which is a very gentle introduction to mirage things, and then
> suddenly drop you into this:
> https://github.com/mirage/mirage-www/tree/master/src
>
> The intention seems to be to present the config.ml and makes you try various
> configurations, but I don't think it works that well: people are going to
> try to understand dispatch(_tls).ml, because that's where most of the meat
> is, and these files are a bit messy, to say the least.
>
> The next tutorials are not really related to mirage (CI, opam, profiling),
> so it is pretty much the end note of the mirage guide.

The tutorial material is quite old and now that we have a considerably
larger set of libraries and facilities, could probably do with an
extensive refresh. I've updated the first three pages that are there
so they match the current situation of mirage-skeleton better --
https://github.com/mirage/mirage-skeleton/pull/98 and
https://github.com/mirage/mirage-www/pull/370 -- comments on either
welcome.

> I see various issues:
> 1) mirage-www is not minimalistic. Now that mirage-seal is here (and in
> particular the static files[2]), maybe that should be used instead
> 2) Defining a unikernel that serves stuff to the web is a good amount of
> boilerplate. Also, considering the amount of indirections, this boilerplate
> is not obvious for a beginner. The main file is basically 100 lines of
> plumbing to be able to call the dispatch function. This boilerplate is now
> embedded into mirage-seal which is very good, but I think it should be put
> into a small reusable library.
> To add insult to injury, some of this plumbing is responsible for setting up
> the tls chain, and we all know this code should really not be done by the
> end user (regardless of how easy it is, by comparison).
> 3) The tutorial doesn't really explain the relation between various
> libraries that you end up using, in particular how the various cohttp things
> fit into the grand scheme.

Agree these are issues :)

> I wonder how feasible it is to define various new modules/combinators that
> are usable in the config files, such as a fully setup HTTP(S) *server*
> stack, or a crunch device (without the need to redefine read_fs[3]
> everywhere ...). The main issue I see is that it adds even more things in
> mirage/mirage-types....

It would be nice not to have to redefine read_fs everywhere, certainly.
I don't see a problem with extending mirage/mirage-types per se.

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

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