MirageOS support?

[dinosaure]

Hi, I'm a bit interested to use dream with MirageOS. However, with a quick look, dream needs to use something else than gluten to be compatible with MirageOS (for instance, mimic). That mostly mean a deep (but not so hard and long) work on the stack.

So to preserve our times, I would like to know if you are interested about that too :+1:. If it's the case, I can try to minimize as much as I can patches to be compatible with MirageOS and propose something which will surely change your dependencies graph.

I would like to say that, from my quick look, dream seems designed as a library which does not really use Unix stuffs (expect for the entropy) which gives to us an opportunity to be compatible with MirageOS.

[aantron]

Yes, I am interested in something like that, again in principle, as in #3 :) Though if you'd like to experiment in parallel, we can also reconcile later — I realize I'm becoming a bit of a choke point myself.

I would like to say that, from my quick look, dream seems designed as a library which does not really use Unix stuffs (expect for the entropy) which gives to us an opportunity to be compatible with MirageOS.

That's right. In fact, Dream doesn't "really" use Lwt either — it's designed to be ultimately portable to Async, probably effects, or some other model. But it needs to have some initial implementation, of course, hence some Unix and some Lwt.

Dream also hides the HTTP server completely. I originally wanted it to be immediately portable to Cohttp, though, in practice, I abandoned keeping it internally portable within a couple of days. Nonetheless, there is nothing in the API that would restrict that.

Thanks for the link to mimic — I hadn't been aware of it at all.

[dinosaure]

Ok, I think the door is open and, as I said we should take the opportunity as soon as we can (before to handle legacy stuffs), so I will propose something with mimic. As I said, it will change your dependencies graph but we can iterate then safely and see what is the best for all of us 🙂 .

[aantron]

Also, I don't know if this is relevant, but Dream has/had OCaml-TLS support. I just eventually hid it from the interface because I did not successfully implement the full ALPN process I needed (IIRC I needed some upstream patch to OCaml-TLS, that I wasn't prepared to do so early in Dream development, but I am hazy on this now):

https://github.com/aantron/dream/blob/10147a69ac644cb458938eaa160b9af8f20c4365/src/http/http.ml#L515-L527

I eventually hid OCaml-TLS from the API to keep it tidy. You could originally pass ~https:`OcamlTLS instead of just ~https:true, as now.

Anyway, I am interested in eventually restoring this in some form.

(before to handle legacy stuffs)

What do you mean by legacy here?

[dinosaure]

What do you mean by legacy here?

Ah it's a theory about the software entropy (or the Zawinski's Law). The more the software lives, the more complicated it becomes to change the base (because the legacy). Fortunately, it's not your case yet (but hope that it will be!)

[dinosaure]

See #22

[hannesm]

Now that the live website https://mirage.io is using dream (from a custom branch, master+mirage at https://github.com/TheLortex/dream), would it be possible to merge that work back into dream?

Also, when compiling that branch I see some deprecation alerts of vendored libraries (paf), maybe a good time to switch to released versions thereof or figure out how to merge patches back?

Thanks a lot for dream, and the work around it /cc @dinosaure @TheLortex @aantron NB: I would like to use dream in a MirageOS context and appreciate released packages over pins to specific branches.

[aantron]

@hannesm I haven't yet had time to properly try out the Mirage support, and to take on its maintenance, because there were, until very recently, still "core" rewrites to do to "Unix" Dream, and I needed to focus on those first. Now that the core is rewritten so as to support the client, and once I see that it is mostly stable, I'll be much more ready to keep up the Mirage support without relying so much on @dinosaure to do the work (for which I have to thank him very much!).

[aantron]

We now have initial Mirage support (dream-mirage.opam, unreleased), and it's tested in CI. We can release the package once it matures somewhat more. I'm going to close this issue for now in favor of specific issues that may arise.