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

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

> 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 
them.

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?)

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