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

Re: [MirageOS-devel] V1 vs V2 mirage-types

> On 12 Nov 2014, at 19:09, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>> slowly following up - I still do not understand why we would want to
>>> have two interface versions here -- shouldn't versioning be kept at
>>> the package level rather than the interface level.
>> I don't know (yet) the specifics of mirage but having thought about that in 
>> another context (assemblage) I also think that module signatures for API 
>> versioning seems to be a rather bad idea and could be a source of subtle 
>> bugs in the future. Not to mention that once you will have the relief of 
>> having solved the versioning problem at the package level it will only be so 
>> soon that you have to deal with it again in your code.
> It's certainly true that the V1/V2 stuff is confusing and hard to explain to 
> new users (and to ourselves, which is a bad sign). It sounded like a good 
> idea at the beginning, and we did that to mirror the xen-api versions bumps, 
> but it our current use of API versioning doesn't really seem to help to 
> actually manage different API versions.

It certainly is confusing.

> One way to fix that is indeed to remove all V1/V2 stuff, and propagate 
> version constraints of opam packages in the mirage tools. Every major version 
> of mirage could then define the set of implementations which satisfy the 
> current mirage-type interface.

I was hoping that Mirage would grow a set of interface conventions over time, 
and I was guessing that these would manifest as common module signatures. For 
example, one of the nice things about Unix is that âeverything is a fileâ and 
therefore supports the same read/write interface. I was wondering if something 
like FLOW might emerge and fill a similar niche in Mirage. If âeverything is a 
FLOWâ then we could create a nice set of utilities to manipulate and compose 

Perhaps the FLOW signature should be taken out of mirage-types and placed in 
its own package (mirage-flow). It could then be versioned separately and we 
could also include a nice set of utilities in the same package?

Would that be better? (or worse?)

MirageOS-devel mailing list



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