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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 13 November 2014 17:30, david <unitedbiscuits@xxxxxxxxx> wrote:
> On Wed, Nov 12, 2014 at 11:24 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>
>> For example, the Fat module implements the V1 FS interface. Maybe it
>> will never be updated to the V2 FS interface, but I might still want
>> to use FAT in my programs, alongside other, newer, filesystems.
>
> Wouldn't that suggest that Fat was unmaintained and should be either
> dropped or ported?

In an ideal world, perhaps. But even if so, consider this scenario:

I have a unikernel using V1 FS and V1 NETWORK. Mirage 2 is now stable,
and I want to migrate to the V2 APIs. Of course, I prefer small
incremental changes, so I'd like to upgrade the FS code to V2 this
week and test it, then upgrade the net code next week.

Making it hard to run with a mix of versions makes upgrading harder
(or impossible, if one library isn't maintained), and that in turn may
cause people to stick with the old versions (cf Python 3).

I don't think it's a problem in the case of Mirage 1 -> 2 because
there's so little existing software, but in general it may be.

>> One reason to try to support backwards compatibility now, when we
>> don't really need it, is to learn how we should do it for the future.
>> Although perhaps it's too soon for that.
>>
>>> I've still to see the use case where we really want to use _old_ and
>>> _new_ mirage APIs side by side in the same application (or the missing
>>> piece why we would want to have multiple API versions)...
>
> Same here. I'm trying to come up with a scenario where having
> multiple, frozen API versions would be useful.
>
> The best I can imagine is having, say, V1, V2 and V3 and V4 with all
> the up-to-date modules adhering to V4. Now if Fat was stuck in V1, one
> of these things must be true:
>
> - I can write my app against FS V1 and use any of the filesystems. Or
> against V2 because I don't need Fat but want another module that's
> stuck to that. Or V3. Fortunately, every single up-to-date module in
> Mirage supports every single historical API version so I can pick the
> API that suits me best.
>
> - Or, if not all modules support every single API ever frozen, and I
> cannot really exchange V1 with V4, what V1 abstracts over at that
> moment is close to nothing. I'm matching the signature of a particular
> unmaintained module to use it and it is impossible to swap it out
> without changing my client code. I'm better off with not even invoking
> a Mirage module type.

That doesn't follow. I use mirage to select lots of modules, even
though in many cases there's only one option for a given platform.
Apart from anything, I may still want to switch between Xen and Unix
flavours of the same component.

> And in all probability the future is closer to #2, with modules
> variously adhering to random old API versions, depending on when
> exactly they were last updated.
>
> I personally can't piece together a picture where V#n helps
> compatibility and it feels a little contrived.
>
> The way I've seen projects usually deal with this is naturally
> converging the interfaces to a relatively stable form after some
> exposure, testing and usage, and then infrequently breaking them and
> simply forcing everybody to upgrade. These painful periods are helped
> by versioning and software archives.
>
> Cleary I might be missing the bigger picture here, but my current
> thinking is that nothing helps with unmaintained libraries and API
> snapshotting just doesn't feel right.
>
> David
>
> --
> "Linear Time is wrong and suicidal." -- Gene Ray



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
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