[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

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.