fwiw, and without fully understanding your point 2 below, i think that having all the type signatures baked into a single library is also rather clumsy... modularity FTW! (when supported by assemblage perhaps ;)
Agreed, but as noted, there's a design tradeoff required. Putting type *signatures* into a library is dependency free (i.e. mirage doesn't depend on the entire universe of mirage libraries). We can indeed split out the type signatures into libraries, but this will take some time and is a lesser concern to me than ensuring that IPv6/SSL/Vchan/Ctypes all hit the trunk as soon as possible.
Also, multiple implementations, living in different opam packages, might satisfy the same signature. In that case, it is not properly clear where that signature should leave. The answer is probably in an other independent opam package.
So that means:
foo-type: the definition of the mirage FOO signature foo: the functors for FOO. Depend on foo-type as we want to check signature/implementation matching at compile time. Depends on bar-type, baz-type, etc... foo-unix: the implementation of FOO for unix. Depends on foo. foo-xen: the implementation of FOO for xen. Depends on foo. foo-mirage: the implementation of the combinators for foo-type. Depends on foo-type. Might add a dependency on a specific versions of foo-unix and foo-xen if the right combinators are used when used in a config.ml. For each new versions of foo-unix and foo-xen, we need to upgrade the constraints (which might be painful) to ensure backward-compatibility. Or we can have open constraints, and do a minor release with the right updated constraints before bumping the major version number.
Then when you want to use foo in your project:
$ opam install foo-mirage
In your "config.ml":
open Mirage (* to load the basic combinators *) open Foo_mirage (* to load the combinators for foo *) let main = foreign "Make" (foo @-> job)
And finally:
$ mirage configure [--xen]
will install either foo-unix or foo-xen automatically, depending on having [--xen] or not on the command-line (as the mirage tool does currently).
- 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.
That "wonderful" system has been build in a couple of days, under the Cambridge snow, so I have some excuses :p
Any objections to this plan, make them really soon. I want to start serving openmirage.org through ipv6/tls asap :-)
no objection, this sounds good.
Thomas
-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
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
