Congratulations to the VMware engineering team releasing the official guide to creating VMware plugins. Their awesome, hard work is culminated in the document Getting Started with VI Client Plug-ins. Several of you have already asked me how their official methods and plug-ins compare to my previously published guide and plug-ins. After a cursory review of the official guide, here are my thoughts:
- The VMware guide to plug-ins is official. Mine is not. Although the VMware guide is experimental, it is more likely to be supported by VMware than any plug-in you write using my guide. That said, I have heard that the team responsible for plug-ins plans on developing a shim that will continue to support my plug-in methods in the next version of VMware Infrastructure (VI). That is hearsay, however, and it could change.
- Official plug-ins function very similarly to mine (they should, they are built using the same principals), but they could be considered inferior in one very important manner. Although the user interface to activate a plug-in is the same (context menus, tabs, menu items), the interface for official plug-ins can only be a web page. For instance, a user right-clicks on a virtual machine and clicks on the context-menu item labeled Migrate storage which launches my Storage VMotion plug-in rewritten as an official plug-in. Instead of having a Windows form appear that maintains a consistent user interface, instead a web browser appears and runs a script or web application that has authentication information and object information passed to it from the VI client (much like my Invoke plug-in).
- Official plug-ins must reside on a web server to which clients have access. This can be considered a good thing and a bad thing. On one hand, it centralizes plug-in updates. On the other hand, if the web server is offline ESX admins could lose plug-in functionality that they have come to rely on. Plug-ins written using my guide reside on the local client; always online and accessible.
- Given how hard it is for developers to build consistent web applications between browsers (even the VI online web interface fails to work properly on Safari), it is a tall order to expect plug-in developers to create plug-ins that look the same between the four major web browsers available to Windows (IE, Firefox, Safari and Opera). That said, you could just force users to use IE since you know it will be there.
- One big win with the official method is that the plug-ins could be written to be standalone web applications. This means that they could be accessed outside the context of the client.
The official plugin guide is a great achievement on the part of VMware; it shows their commitment to giving users what they want. Ultimately, though, the plug-ins created with it are forced to be web applications or scripts hosted on a web server. The biggest problem with this is that it forces users to leave the consistent look and feel of the VI client, ripping them out of their experience. The official plug-in guide is probably best thought of as an online alternative to the Invoke plug-in, but not as a replacement to the plug-in architecture that I have already exposed.
Hopefully with VI4 we will see a more fully fleshed out, official plug-in architecture.
Carter Shanklin, Product Manager of End User Enablement at VMware, sent me an email with the following note:
One point you make is the inconsistency of browsers in rendering, etc. Inside VI Client, if you create a custom tab it will be rendered using an Explorer control, regardless of what your preferred browser might be. This may be problematic if you want to use the same interface from outside of VI Client, but from within the client it should look fairly consistent.
Carter is absolutely correct. These controls should be rendered within the VI client, however you still need to make sure your web application looks and feels like a part of the VI client. Just because your web application is displayed from within the VI client, it does not mean that the VI client is rendering your list box or text box with its own style sheets.