Re: [MirageOS-devel] mirageos 3.0 : let's break some APIs

[Thomas Leonard <talex5@xxxxxxxxx>]

On 18 May 2016 at 17:28, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:
> Hi folks!
>
> With some exciting new developments (OCaml 4.03 with flambda, `result`,
> `logs`) and users, it's probably time to think about the broad world of
> possibilities unlocked by big changes to mirage-types. Here are some things
> that recently have been mentioned:
>
>
> * rename the `V1` and `V1_LWT` modules to something unversioned, like `S` or
> `MIRAGE`
>
> * replace or augment the `error` types with Result.result
>
> * break up `mirage-types` into a package per module type, so module types
> can be independently changed and released
>
> * changes to the semantics of functions in low-level module type definitions
> like `FS` and `NETWORK`
>
>
> I'm surely missing many things folks would want to incorporate in a big
> API-breaking release -- please do let us know what they are. :)
>
> Also, if you have any long-standing PRs or issues that are blocked because
> you don't want to do a big API-breaking change, links to them would be
> appreciated.

I'd very much like to make it easier to do API changes without having
to update everything at once. These issues are probably related to
this:

https://github.com/mirage/mirage/pull/383 (Add `pp_error` to FLOW and
use a result type, from 2015)
https://github.com/mirage/mirage/pull/286 (Support checksum offload, from 2014)

Looking at the git logs for mirage-types, in the last 12 months we
only made one change to an existing module type, which was to remove

  val input_arpv4: t -> buffer -> unit io
  (** {b FIXME} *)

from IPV4. I guess this API had only one user (tcpip, which provides
both IP and ARP implementations).

This could mean that our APIs are nearly perfect and we can't think of
any improvements. But it could also mean that updating them is too
hard. The more implementations of an interface we have (e.g. Unix,
Xen, Solo5, JavaScript, etc) the harder it becomes to get them all
updated and released together.

If we could include multiple versions of an API in mirage-types, we
could release things in stages. e.g.

1. Add MIRAGE.NET.V2 to mirage-types.
2. Release mirage-net-xen, mirage-net-unix, mirage-net-... providing
V1 and V2 implementations.
3. Release tcpip with support for V2.
4. Update the mirage tool to use V2 to connect tcpip to net.

Note that providing both versions of an interface is typically very
easy. In this case, V1.write would call V2.write with the default
flags, and V1.listen would wrap the callback argument with one that
discarded the flags.


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel