[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Serving each URL from a separate unikernel: an experiment

On 27 March 2015 at 17:53, Jeremy Yallop <jeremy.yallop@xxxxxxxxxxxx> wrote:
> On 27 March 2015 at 17:28, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> On 25 Mar 2015, at 15:57, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>>> Hash: SHA384
>>> On 03/25/2015 15:43, Mindy wrote:
>>>> Also, none of the unikernels expect to serve anything but their
>>>> front pages, so one could probably remove the path-matching logic
>>>> from dispatch.ml, and just always serve the (only) contents of the
>>>> KV_RO fs. :)
>>> yep... that's what the btc piÃata does (here:
>>> https://github.com/mirleft/btc-pinata/blob/master/unikernel.ml#L109,
>>> where page is cow
>>> https://github.com/mirleft/btc-pinata/blob/master/page.ml). no
>>> dispatch involved, it doesn't even wait for the GET request.. :)
>> My MetaOCaml bleeper just went off!  It should be possible to stage
>> the dispatch function and emit a dispatch-free version by
>> partially evaluating it with the URL.

Is this the dispatch function in question?


That certainly looks very stageable, but I think you'd have to
eliminate the lwt syntax, since MetaOCaml and Camlp4 don't currently
play happily together.

Of course, once you start staging away overhead it's tempting to keep
going, so you might end up transforming everything down to a single
call to write a string literal.

MirageOS-devel mailing list



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