We have developed a vCenter Html plugin two years back with technologies in UI like, Angular, Clarity design system .... There was also lot new developments on the backend.
Now we are in the process of developing remote plugin.
First off i am trying to research / understand what is the difference between the previous one and the new remote plugin?. Any pointers in this regard... (I am reading the vsphere-client-sdk-673-remote-programming-guide.pdf for now)
Also while going over the documentation of vsphere-client-sdk-673-remote-programming-guide.pdf found few new things, like below.
Now should we update our plugin code as per new guide. I am seeing in the guide that accessing window.parent is not recommanded... PFA screenshot.
Please share few inputs, thanks.
The main difference between local and remote plugins is that remote plugins run on a separate appliance i.e. it they do not run in the vSphere UI server (Virgo). It is up to the remote plugins to provide their backend appliance.
Remote plugins running in a separate appliance solve the issue of shared dependies between the core vSphere UI and plugins and it also allows remote plugins' backend to be written a language different than Java.
Now on the other two questions:
> Found the plugin manifest file type is changed to plugin.json. Previously it was plugin.xml file with its own definitions of plugin, resources, extension.. Now I am not sure how much of this is supported with new format of manifest file type plugin.json.
The new plugin manifest format is much simpler than the old one. You don't need to use complex extensions and extension points any more as in the new format the set of extension points and the way extension are described is simplified. As a result of this the new format does not support all of the old format's extension points. The new format allows the SDK to validate a remote plugin's manifest during deployment and fail the deployment if the manifest does not have the correct format e.g. missing required properties, misstyped properties, non-existing properties, invalid property values or types etc. The full description of the new format schema can be found here: https://code.vmware.com/web/sdk/67/client -> vSphere Client Remote Plug-in Extensions Reference (https://vdc-download.vmware.com/vmwb-repository/dcr-public/158d4b12-3175-4913-8da3-a0a7b2b58a5b/2b52...).
Thanks for the quick reply.
Thanks for explaining difference between the local and remote plugin.
Our plugin developed back in early 2018 (previously it was a Flex UI plugin so we have moved to Html UI plugin) is using the WEB_PLATFORM APIs as per the vSphere standards back then. While researching about the remote-plugin development found that there is new changes like new APIs and plugin.json file...
Can you please let me know what you think.
Also our plugin is in a separate repository before and now we are planning to move to new repository with new structure and everything, Is this necessary change?. PFB screenshot where we will have the plugin ui code.
I would suggest that you start migrating your plugin to a remote plugin. If you hit any issues while migrating please feel free to ask questions or contact us so we can resolve the issues or implement the necessary changes if needed. We're still supporting the WEB_PLATFORM APIs in the vSphere 7.0 release.
It's hard to estimate how long the migration will take without knowing how and which JS APIs your plugin is using. Some of the old JS APIs do not have an equivalent in the new JS APIs and would require bigger changes in the plugin code. Also remote plugin architecture is different than local plugin architecture in several ways. Additionally you have to take into consideration what extension points your plugin is utilizing now and whether they have a remote plugin equivalent, if they don't you will have to make changes to the plugin UX.
Additionally we've provided a migration tool for remote plugins, you can find it on the SDK home page.
Thanks for the reply.
It's good to know that WEB_PLATFORM APIs are still supported in vSphere 7.0. This will certainly give us needed time to migrate.
Our plugin is really vast we are using so many APIs and extensions. I am not sure if i can share more information in this regard (I will get approval from my manager), but we have extensions with extendedPoint like "vsphere.core.datastore.summarySectionViews, vsphere.core.datastore.monitorCategories, vsphere.core.datastore.monitorViews ....", so if few of these extensions are not supported then we will have to look at new UX as you mentioned and this we can only plan after doing the necessary research.
Maybe for now we will move our code base of the plugin-ui to the new folder structure (remote-vcp/src/main/ui) and just change the wiring of the endpoints and plan the migration with a future release.... Question: Why do we have a ui folder here, i understand this is the location of the plugin-ui, so when vCenter is registered will this be plugin-ui that is deployed in the vSphere Client UI of the vCenter.
Also i am still trying to understand the remote plugin architecture, different from local plugin architecture!!, I am doing some reading... can you please share some docs or videos in this regard.