[sequoyah-dev] p2 discovery ui issues for pulsar sdk view

[<David.Dubrow@xxxxxxxxx>]

Title: p2 discovery ui issues for pulsar sdk view

These are a few things I’ve been thinking about regarding the work on the Pulsar view. We probably would need to get consensus before work could begin.

1. The p2 discovery catalog viewer does not support uninstalling but the Pulsar SDK view does. I see 2 possible approaches since we obviously would want to maintain the existing uninstall functionality in Pulsar:
   
   • Use a customized version of the discovery catalog viewer – I really don’t like this because it adds a lot of custom code we would have to maintain and potentially more development time we don’t really have.
   • Support uninstall through a separate dialog that could be invoked from the pulsar view rather than through the main UI. For example, the current uninstall toolbar item could bring up a dialog listing installed sdks and allow the user to uninstall them.
     
2. Tooling: As far as generating the p2 discovery metadata, my feeling is that if we take this on with the metadata tool, it will be too much work for very little benefit. The p2 discovery metadata is deployed in the form of small eclipse plugins that can be hosted remotely. These plugins contain extensions (in the plugin.xml) as the metadata. The p2 discovery UI pulls in these plugins to provide the icons, screenshots, urls, descriptions, etc. as well as pointing to the current pulsar installable units (we will still need the p2 metadata generated by the current metadata tool). So rather than providing additional pulsar tooling to generate the p2 discovery ui metadata, I propose we use eclipse’s existing support for (1) visually editing extensions (i.e., the plugin.xml editor) and (2) creating a plugin (i.e., “export” deployable plugins wizard). We can explain the process to the sdk providers. In addition, we could deploy the pulsar UI such that it can read the discovery metadata plugins directly from the workspace (i.e., the current installation), so it can be easily tested locally during development without having to deploy it to a server.
3. Backward compatibility of pulsar metadata: I presume we will need to continue supporting existing Ganymede based pulsar tools. So if we decide we need to provide a different metadata model for the Helios based tools (I don’t expect this), sdk providers can leave existing metadata on the servers and add the new metadata for the Helios based pulsar tools to a separate location. Otherwise, we can try to structure the new metadata such that it is backward compatible. I don’t this this will be an issue, but we should know both options are available if necessary.
4. Forward compatibility of old metadata that has not been augmented with the new p2 discovery metadata: I think we should require sdk providers to update their metadata in order to be usable in a Helios pulsar. The alternative of having to generate catalog items on the fly and populate them with the old style metadata (small icons, etc.) is not going to provide anything worth supporting. Additionally, I have not looked too much into this so there are unknowns and the work may not be trivial.
   

David Dubrow