> From: David Nalley [mailto:[email protected]]
> Sent: Thursday, August 09, 2012 9:58 AM
> To: [email protected]
> Subject: Re: [DISCUSS] VMware support was: Re: vijava - some additional
> thoughts
>
> On Thu, Aug 9, 2012 at 12:44 PM, Will Chan <[email protected]> wrote:
> > I prefer the same option "remove VMware SDK from the build" idea as
> well. I wouldn't even go as far as adding in other libraries. If people
> want to
> use VMWare, I am hoping we can just give them additional instructions on
> how to do that.
>
> I am not opposed to dropping VMware support from the default build for
> 4.0, but continuing forward with after that when there are (at least
> potentially) two alternatives that would permit us to provide VMware
> support in the default build and convenience binaries strikes me as a
> disservice to our users.
>
> --David
The issue with using some open source version of the vmware SDK is that it is
not as well tested as the official one. Even things like the vmware tools that
you have to install in guest VMs have issues in feature supports between the
open source version and the official one (based on Citrix testing). In my
opinion, if there is any way we can continue to use the official vmware SDK but
perhaps make it a bit of a nuisance to get it to work is still better than
using another library that isn't as stable and dealing with workarounds to make
it work. Another plus is that you will get Citrix QA for free on testing the
vmware SDK on all vSphere versions (4.1, 5.0, and 6.x when it's released).
Bottom line is that by using other alternatives, I would hate to have code
that says if (sdk == opensource version) { do this workaround...} else {do what
the official SDK allows }. Of course, someone could probably refactor some of
the code to be a bit more pluggable as to what thirdparty libs are being used
but I doubt it's doing that today.
Will
