The road to stable vSphere Client plugins (Part 2) – Lessons learned!

In part 1 of “The road to stable vSphere Client plugins” series we looked into the most common plugin errors and the known stability challenges in the field.

It is important to spot certain trends and categorize them to allow adequate troubleshooting now as well as long-term architecture and design decisions for the future of the plugin ecosystem.

The fragile web-platform.js as an extensive plugin-side API

The web-platform.js was designed as a simple way to provide helpers and API methods to fetch the current context from the Client URL. Its goal was to work on both Flash and HTML clients for the so-called Bridge plugins.

While achieving this goal the web-platform.js served as not a mere proxy between the plugin frontend code and the platform through the iframe but contained actual implementations and was embedded separately by each plugin.

The downsides of this approach in the context of the HTML Client itself include:

1. Every change to an API method requires fixes to the plugin. Conversely this forces a new plugin release.
2. The lack of platform-backed versions of the API means that the vSphere Client product cannot grow or adapt without impact on the ecosystem.
3. External factors like browser implementations (e.g. the Chrome breakage) can force plugin repackaging.
4. Multiple plugins might change a shared object delivered to all iframes, thus impacting each other.
5. API for general-purpose operations that can be replaced by a few lines of standard JS code are irrelevant.

Using the URL as an implicit API

Utilising the URL to deliver data has the perk of easy access by plugins to the current context within the Client: selected inventory object, locale, custom parameters, etc.

Unfortunately, this comes with a number of downsides which can be critical in an enterprise environment:

1. There are Security implications stemming from the nature of URL parameters as publicly exposed data.
2. URLs containing lots of context are likely unstable.
3. URL params bring unclear semantics of what they represent and can be used for.

Too many shared platform resources with limited customizability

The fact that plugins are deployed inside the vSphere Client’s application server and share the same OSGi container means that the Client and all plugins share the same resources:

1. Common libraries – plugins are forced to use particular versions of libraries delivered by the platform (e.g. Spring).
2. Common runtime – a plugin can impact another at runtime or slowdown the Client.
3. CPU & Memory – a plugin starting many threads, consuming lots of memory or CPU can impact the whole vSphere Client and other plugins.

Generic extensible architecture

The desire for generic solutions is what every engineer inherently strives for. Despite that, when the users of these solutions have different goals the “generic” might become costly. In the context of the vSphere Client the same generic extensibility has been the platform for both core features and UI plugins:

1. While very flexible this means complexity: core UI based on extensions which, themselves host plugin extensions.
2. Changes to core UI can potentially impact backward compatibility of plugin extensions.
3. It is not dedicated to plugin use cases but provides a large API surface most of which is intended to be used only by core UI extensions and is not publicly documented.

Last but not least, we should mention documentation. While containing the most common info it has often been outdated or misaligned with the actual implementation. The missing or unclear details of the big picture for plugins, as well as the rare ability of the SDK team to share code with the community (e.g. only at official releases) has contributed to common misunderstandings by plugin developers – partly remediated via the Forum.

This has been the analysis of what has lead to most problems in the plugin ecosystem.

In the final part of the series we will look at what the vSphere Client SDK team in VMware has done over the last releases to address the issues. Specifically, we will focus on how the lessons we all learned lead to the robust plugin architecture and solutions of the future that the ecosystem needs.