Community
Participate
Working Groups
The New Connection wizard must instantiate all subsystem configurations for a given system type when that type is selected on the first wizard page. It does this in order to populate the subsequent pages of the wizard. I propose a concept of subsystem configuration families that are groups of subsystem configurations that are meant to act together. These would typically share a connector service but would not have to. A new extension point would define these families. Membership in a specific family would be optional. If no family is specified for a subsystem configuration in its extension point then it would be unaffiliated. Unaffiliated subsystem configurations would always be allowed to present wizard pages. The user would select the family desired up front and only those subsystem configurations in the family would be loaded by the wizard. The family selection UI would be driven entirely by the extension point. When a system type is selected on the wizard the logic to determine the following page would be as follows: interesting families = new Set() for all proxies { if the proxy specifies a family then add that family to the set of interesting families } If there is more than one interesting family then the next wizard page would allow the user to select the family to be used for that connection. If there is exactly one family then that family is selected and the family selection page is bypassed. If there are no families then then no family is selected and the family selection page is bypassed. The following wizard pages would then present only those subsystem configuations from the selected family. If no family is selected then the wizard would present only unaffiliated configurations. I envision 3 families: FTP, dstore, and SSH. Families would be used in two places - the new connection wizard and possibly the properties dialog. But this is a core concept in that the API new connection creation would be able to specify a family - this may be null if only unaffiliated subsystem configurations are desired. Service subsystem switching should probably no longer be allowed in the properties dialog for an existing connection. Or it if were, I would propose that we replace it with subsystem family switching and do it at the connection/host level. Comments?
I think that the problems you observe with subsystem instantiation in the wizard would better be solved with a generic improvement of making subsystem associations more dynamic (i.e. allowing subsystems to be added/removed from a connection after it has been created; bug 150498, bug 174495, bug ), and redesigning the wizard (bug 176490). Perhaps I'm not understanding this request properly, but I'd think that a good wizard should be capable of presenting a selection of subsystems based on their plugin.xml markup only, and only once the user has selected a given set of subsystems forces their instantiation. Such an approach should work without subsystem families, thus I'm against adding this concept. If you agree, please mark this bug INVALID or WONTFIX.
(In reply to comment #1) > I think that the problems you observe with subsystem instantiation in the > wizard would better be solved with a generic improvement of making subsystem > associations more dynamic (i.e. allowing subsystems to be added/removed from a > connection after it has been created; bug 150498, bug 174495, bug ), and > redesigning the wizard (bug 176490). I think these are independent of this particular problem. Although redesigning the wizard would help. Is there enough information in the subsystem configuration markup to present a UI? > > Perhaps I'm not understanding this request properly, but I'd think that a good > wizard should be capable of presenting a selection of subsystems based on their > plugin.xml markup only, and only once the user has selected a given set of > subsystems forces their instantiation. I think that SubSystem families provide the markup you are looking for. > > Such an approach should work without subsystem families, thus I'm against > adding this concept. If you agree, please mark this bug INVALID or WONTFIX. > Can you give an example using the current markup of how we might do this? The one I can see is the equivalent of splitting the current wizard page for service subsystems into two, the first to select the subsystem configuration and then the properties page needed by that particular configuration. This would probably still require extra markup in the subsystem configuration for help and perhaps other descriptive text. It would also allow the user to select a dstore file subsystem with an SSH shell subsystem.
When I'm understanding this right, the original problem was to understand what subsystem configurations are tied together with the same connector service, without instantiating them. So, the most straightforward solution that I can see is to extend the plugin.xml markup of subSystemConfiguration such that it has an additional required slot "connectorservice" of type "String" with Meta-Info "Java Class". This clearly defines what a family is. In fact, the change could even be made backward compatible such that access to the slot is via a new method String ISubSystemConfigurationProxy.getConnectorServiceId() which returns the string without activating the subsystem for new implementations, but activates the subsystem configuration for old implementations such that it can read the connector service class from it. The only potential issue I see with this approach is that currently, ISubSystemConfiguration.getConnectorService(IHost) could potentially return DIFFERENT classes extending IConnectorService depending on the kind of host being passed into it. With a static markup via plugin.xml that would no longer be possible, and all connector services returned would need to be of the same class. Thoughts?
Families and connector services were meant to be similar but not necessarily identical. Two configurations could belong to the same family but not employ the same connector service - although this might be odd. On the other hand the family notion might be overkill, and this suggestion be what most folks are looking for. There would need to be more information supplied in the plugin.xml to construct a UI that allows them to select the connector service in the wizards and properties. Or should users be allowed to select and activate multiples? I'm not sure there is a problem with ISubSystemConfiguration.getConnectorService(IHost). I think all currently implemented subsystems employ only one connector service type for all hosts. One problem I see is that the information about a connector service is shared across multiple subsystem configuration definitions. If two specify the same connector service but the other information is in conflict, which one wins?
Not for 3.0
Marking as performance related, since this bug is about avoiding unnecessary plugin activation.
