[vbox-dev] Deprecated webservice APIs in 3.2 ...

Thu May 20 11:30:57 GMT 2010

Joe,

I think you are calling getCPUProperty with its old name getCpuProperty (capitalization).

As I said, we recommend querying the version after connecting to the API. We cannot really version the API in a sensible way because the changes are not done in a compatible manner, i.e. methods disappear and method signatures change. For the Java bindings we used the package name space to allow you to load several versions, I do not know enough about the PHP API to make any statements. Maybe you can elaborate on your suggested change for PHP and Python?

I can understand your concern but the best answer I have is that you don't have to follow every update. This is how we work with most large consumers of our API. They migrate from VirtualBox 2.0 to 3.0, from 3.0 to 3.2, etc. Virtualization is still a very dynamic market and innovation happens at rapid pace but this will certainly cool down over time. This doesn't mean that we've run out of ideas though :-)

Achim.

On May 20, 2010, at 13:19 , Joseph Smith wrote:

> Hi Achim,
> 
> Thanks for the quick reply.
> 
> I definitely appreciate the need to keep a clean design and applaud that.  Since the VirtualBox development team is so good at cranking out enhancements ... major version releases happen rather quickly (for 3.1.x to 3.2.0 it's only been about 5 or 6 months).  At that pace, it means an average or twice a year the API consumer community can expect to see a major release that could have a significant impact ... hmmm ... this could be a challenge in larger implementations as some deployment cycles may not be that quick.
> 
> My suggestion (actually a request) for having the version number be part of the generated modules was also an attempt at ensuring the middle layer (PHP, Python and other generated API interfaces) along with the WSDLs are a compatible or known version.  Since WSDL and generated filenames do not change, the only way to determine a difference is to diff a known file against another known file ... not the most elegant way to do that.
> 
> With no embedded 'version' elements, it makes it impossible to programatically ensure the generated modules we are using match the version of the APIs themselves.
> 
> Do you have any information on the IMachine::getCPUProperty API?  That API per the 3.2 documentation appears to still be supported ... but an attempt to call that API results in the exception I noted below.
> 
> 
> Thanks,
> Joe
> 
> From: Achim Hasenmueller <achim at sun.com>
> To: Joseph Smith <joseph1962smith at yahoo.com>
> Cc: vbox-dev at virtualbox.org
> Sent: Thu, May 20, 2010 5:16:34 AM
> Subject: Re: [vbox-dev] Deprecated webservice APIs in 3.2 ...
> 
> Joe,
> 
> the policy is that when we do a major update (first and/or second digit change, 3.2 is one), we may change APIs in incompatible ways. This is is a burden on the API consumer but it allows us to keep a clean design and not accumulate legacy. Within one major version (e.g. 3.1.x), we guarantee API stability.
> 
> Regarding versioning, the first call you make should be to query the VirtualBox version number. Then you know which API is in place and in your code, you should differentiate between versions and make the appropriate calls.
> 
> Ideally, we document all API changes in the SDK manual but unfortunately that didn't happen for the 3.2.0 release. Some of the changes are explained (section 7.5) but it's not complete. We will address this for the upcoming 3.2.2 service release.
> 
> The IGuest::getStatistics stuff is gone in 3.2 as it was a Windows guest only temporary solution that got finally folded into the more generic metrics API.
> 
> A good way to see what has changed is to diff VirtualBox.xidl which is the abstract definition of our API. You can find the trunk version here: http://www.virtualbox.org/browser/trunk/src/VBox/Main/idl/VirtualBox.xidl
> Just diff the one from the 3.2.0 tarball and the one from 3.1.8 to get an idea.
> 
> Achim
> 
> 
> On May 20, 2010, at 10:27 , Joseph Smith wrote:
> 
>> Hi,
>> 
>> I am currently using VBox 3.1.6 webservice APIs (PHP version) and decided to make the jump to version 3.2 (skipping 3.1.8) as I thought it was time to 'get caught up'.
>> 
>> In doing so, I got caught by a few surprises.  I have only begun initial testing ... here is what I've found thus far:
>> 
>> 1) IMachine::getCPUProperty throws the following exception:
>> Method 'ns1:IMachine_getCpuProperty' not implemented: method name or namespace not recognized).  The method is described in the WSDL and so is the CPUPropertyType.  PHP API wrappers also appears to be correct.  Was this method deprecated?
>> 
>> 2) IGuest::getStatistic (required a parm of 'GuestStatisticType') does not seem to be a valid method any more.  Appears to have been replaced with IGuest::internalGetStatistics.  From the 3.2 API docs ... seems this method is intended to only be called internally?  What does 'internal' mean here?  I am assuming the getStatistic method was deprecated?
>> 
>> 3) IDisplay::getWidth,  IDisplay::getHeight and  IDisplay::getBitsPerPixel do not seem to be valid any more.  Appears to have been replaced with IDisplay::getScreenResolution.  I'm guessing here the width, height and bpp elements were depricated?
>> 
>> Thinking I missed something ... I went back and looked at the 3.1.8 docs to find where deprecated functions were listed ... and found the usual IVirtualBox::createLegacyMachine and IVirtualBox::openMachine listed ... but nothing else.
>> 
>> Some questions:
>> 1) Where are deprecated and 'planned to be deprecated' APIs and fields/elements listed?  Is it somewhere else I should have checked?
>> 
>> 2) What is the deprecation policy?  How far in advance will APIs be advised of deprecation?
>> 
>> 3) Generally ... when APIs are deprecated ... they are supported for N past versions ... what is the past-version-support and 'roll-off' duration for deprecated APIs?
>> 
>> I am trying to identify a proactive way in detecting changes to APIs that my solution uses so that I don't have to suddenly react for a new release.  Is there some other documentation that details all this and I'm just not aware of it?  This is not the first time ... a similar situation happened when the more robust and better IMedium and IStorageController approach was added.
>> 
>> May I make a suggestion:
>> WSDL files and the vboxServiceWrappers.php file do not appear have any 'version' related information that could allow an application to be "smarter" about what APIs are available.  Can versioning be added to the WSDL files that correlate somehow to the API version?  Maybe an enumerated list of releases of the VirtualBox application that the WSDL supports ... or even a simple comma separated list of versions?  That way, the generated vboxServiceWrappers.php module (and other generated modules) would also include that information.  It could go a long way in allowing applications to use the version information to make 'smart' decisions about which APIs or features are available or not.
>> 
>> 
>> Thanks,
>> Joe
>> 
>> 
>> _______________________________________________
>> vbox-dev mailing list
>> vbox-dev at virtualbox.org
>> http://vbox.innotek.de/mailman/listinfo/vbox-dev
> 
> 
> 
> 
> 

--
Achim Hasenmueller
Director Engineering, VirtualBox
Sun Microsystems GmbH
Werkstrasse 24
71384 Weinstadt, Germany
phone: +49 7151 604050

================================================
Sitz der Gesellschaft: Sun Microsystems GmbH,
Sonnenallee 1, 85551 Kirchheim-Heimstetten 
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz
================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20100520/837a8da0/attachment.html>