[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Charrua release
On 15 October 2015 at 15:17, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote: >> Hence, putting all code dealing with the wire-to-OCaml interface in >> Tftp_wire, and then (I'm currently fiddling with this, slowly) all the >> state machine logic in Tftp_S with the intent of having a Mirage >> unikernel implementation that uses Tftp_S to create a server instance >> (basically by bridging IO into Tftp_S). > > I'm not sure what Tftp_S is (what the _S should do). From my point of > view: put the (pure!) state machine logic somewhere [by pure I mean it > does not do IO or logging, but uses as signature `state -> bytes -> > (state * action list)`], where state is some abstract type, constructed > via some configuration step, and actions might contain: > `Log "client ZZZ requested image YYY" > `Tell_user "failed to find image YYY" > `Send <packet> > > Or maybe, if sending out a response is common enough, maybe use `state * > bytes option * actions`. > > And then, on top of this state machine, which uses the wire_struct and > some state, use it to build either Lwt or Mirage layers (which translate > actions into side-effecting IO operations). > > We/I tested this approach in > [TLS](http://mirleft.github.io/ocaml-tls/Engine.html) and [OTR (which > does not have any side effects in its > library)](http://hannesm.github.io/ocaml-otr/Otr.Engine.html) Cool-- sounds reasoanble, I'll attempt to follow that. > (yes, my draft text disappeared, but might appear again next week) Look forward to it :) -- Richard Mortier richard.mortier@xxxxxxxxxxxx _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |