>> 2. Compatibility with Oracle VirtualBox is unstable: I defined new VM >> types for Red Hat guests, like RHEL7_64, which Oracle VirtualBox fails >> to understand and renders RHEL VMs inaccessible. > > It also changes the API (and forgets to change the UUID of IMachine, > which means that compiled API clients using the "native" interface would > crash or call the wrong method). If the UUID of IMachine would be > updated then existing 3rd party API clients using the "native" interface > would refuse to work. In other words: there is no solution which truly > solves the incompatibility. > > With the API groundwork of VirtualBox 5.0 it will be possible in the > future to support multiple interface versions once several generators > and tools are extended further (no idea when we have time for this). > Then such API incompatibilities can be handled cleanly. The API wrapper > generator is designed to be far more than yet another quirky abstraction :) >
I don't understand this COM issue at all. Assume IMachine has UUID: 0x1111 IMachine::Foo() has 0xF00 (assume it is part of Oracle's VirtualBox) Now I have added a new main API function in my patch: IMachine::Boo() and decided it has 0xB00 (UUID 0xB00 was never used in Oracle) What is the problem with this ? I don't see how adding Boo() with a new UUID can it possibly break IMachine class or IMachine::Foo() method. Anyway I did test VBoxPython code, and it seems to work. >> 3. License is simple BSD. > > Previously it was MIT, but that's just a reminder. It's your change, and > therefore you're free to use whichever license you like (including > several of them). Sorry it is MIT (X11). This one seems shorter than BSD. _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
