The modularity discussion so far is most interesting -- since we have modular interfaces, and modular implementations, why don't we have modular configuration as well? . There are a few tradeoffs we have to keep in mind to get here:
1) We want to be able to use a stable set of interfaces and implementations, but to move one particular set forward to work on that feature. This is much easier in OPAM 1.2, since we can do "opam install cohttp<0.12.0" to specify an upper bound of implementation that we want installed. This was not available when ThomasG wrote the first rev of the mirage CLI.
2) Mirage-types cannot be moved out to the individual libraries that export the types, since currently our package management granularity means that this would introduce a dependency on the implementation as well. We could have an OPAM "-types" package as well as the implementation (e.g. cohttp-types and cohttp) but I feel that this is rather clumsy. The situation here is improving as we have better control over our build tools (via Assemblage and other emerging systems) to eventually export a finer grained set of OPAM packages with less manual package management.
3) We have to keep moving forward in the short term and not place an undue burden on ourselves for backwards compatibility. There are a number of extremely cool and core features such as Irmin, Ctypes, TLS and Vchan that all need to land in the main branches as soon as possible. Breaking existing unikernels is fine in the short term, but we need to consider the long-term strategy so that we don't wall ourselves in.
Therefore, I propose this plan of action:
- I will delete V2 entirely from mirage/mirage as being unused.
- I will merge the IPv6 patches into *V1* in trunk.
- I will branch mirage-skeleton with a 'dev' branch that works with trunk. It's easier to do that since beginners are likely to clone mirage-skeleton trunk to work with the stable releases.
- The live website will use trunk builds to give us an early warning when things crash and burn.
Medium term:
- We will brainstorm in the next mirage call and in Cambridge about the longer term solution of configuration modularity (which will require some work to get right, and so won't happen in the very short term). ThomasG will lead this one and take the final decision since the existing configuration system is his faul^H^H creation and he understands it best.
- Remove the V1 prefix entirely and just expose the module types in the Mirage module directly.
Any objections to this plan, make them really soon. I want to start serving
openmirage.org through ipv6/tls asap :-)
-anil
Great!
We really need to decide something about the V1/V2, but I'm still unsure what's the best thing to do. I'm happy to brainstorm in a room next week, with people interested by the topic and (ideally) physically present in Cambridge. The goal would be to review the options discussed on that list and propose a design which should improve the current state of things.
Best,
Thomas
Dear all,
As some of you may know I have been working for the last month and a half on adding IPv6 support to Mirage. I am pleased to announce that enough work has been done that we can now serve webpages using cohttp/conduit over IPv6.
If you have access to the IPv6 internet then check out the experimental server (a modified `static_website` from `mirage-skeleton`) at
(If it doesn't work the first time, just reload - there is be a bug somewhere that I haven't been able to trace yet.)
The relevant PRs are:
Things left to do (apart from some odds and ends on the protocol itself):
1. Testing/bug fixing
2. Decide what to do regarding the V1/V2 story.
3. Adapt the `mirage configure` tool (this is intertwined with 2.)
4. DNS support (unsure about the status of this one) ?
5. Update all the examples to work with the new signatures.
Longer-term, better abstractions for the network stack seem to be in order.
There is also a design document that I hope to complete soon and add to `mirage-tcpip`.
I will appreciate any and all comments/criticisms/suggestions/bug reports/etc, either personally, by mail, on the list, on GitHub, or any other way.
Enjoy!
Best wishes,
Nicolas
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxxhttp://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxxhttp://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
