Re: [tm-dev] Questions about current refactor and API

[Greg Watson <g.watson@xxxxxxxxxxxx>]

Rob,

See answers below.

> 
> 
> Concerns on existing API:
> 
> 1) Multiple connection managers may have a connection with the same name. This means it'd be impossible for each connection to have a unique id / name, since a connection named "MyConnection" may be present in multiple connection managers. It is important for our use case that each connection could have a unique id that can be queried / found.

Although it is possible to have multiple connection managers, each one is derived from a specific remote services implementation which has a unique ID. The combination of the remote services ID and connection name is unique. This pair can be safely persisted.

> 
> 2) Related to 1, RemoteServices (commented as 'main entry point') lacks an API to find a connection by name, which would iterate through all RemoteServicesDescriptor's and their IRemoteConnectionManager.

That’s true. This is because calling getRemoteServices() results in a plugin being loaded. Iterating over all descriptors would load all the providers, which is not something that is normally desirable. I’d be ok with providing an API that allows all then available descriptors to be obtained, but it would be up to the client to load each provider, then fetch the connection names.

> 
> 3) IRemoteConnection.getPort()  is very vague. If I wanted to make a connection type which used ftp for file transfer, but ssh for remote processes, having only one getPort() wouldn't be sufficient. Are we sure this should be a public method? Or should it be internal detail for each connection type? Or would we simply discourage such compound connection types and instead request users to instantiate an ftp connection and an ssh connection to the same host? This is some of the flexibility we lose without RSE it seems.

I’m not sure why this is public. We could look at removing this for Mars and see if anyone objects. I would suggest opening a bug for this issue.

> 
> 4) RemoteServicesImpl.fRemoteServicesByScheme maps schemes to a remote services descriptor. If I wanted to make a custom connection descriptor type which has different schemes for different services, (ftp for file transfer, ssh for process building), what scheme would I use? If I also used ssh as the scheme, it seems only one would be present in this map. I'm assuming the 'scheme' here is not simply arbitrary but is part of the connection url / scheme. Or would we simply discourage such compound connection types?

Since you’d be providing your own EFS implementation, you’d also need to provide your own scheme name. The “ssh” scheme is used by the JSch provider, so it would need to be something different, unless you were planning to remove the JSch provider from your product (which is certainly possible).

> 
> 5) IRemoteConnection.getProcessBuilder(etc) doesn't throw any exceptions if unsupported  (for example an ftp connection), and javadoc does not indicate whether null is a valid response.  There also doesn't appear to be a flag in IRemoteServices and the capability constants for whether launching remote processes is a capability, though there is one for remote shell.
> 

I believe Doug is working on providing a more nuanced API that will resolve these issues. I’ll wait until I see what he is planning before commenting further.

> 6) Comments on IRemoteUIConnectionWizard, see below for specific criticism
> 
> Question on upcoming view:
> 
> I understand a connection view is currently in development. I'm wondering if there are any mockups as to how this view would work or function. Specifically, I'm curious how the 'add connection' action would work.  Currently, only the preference page is able to add connections. The UI uses IRemoteUIConnectionWizard, which primarily seems to be used to open a custom wizard depending on connection type. The workflow of this action (from a view) would appear to then be:
> 
>  1) User right-clicks in view and selects new connection (or some toolbar button)
>  2) o.e.remote opens a wizard to select connection type  (ssh / android / whatever)
>  3) A *second* wizard must be opened via the IRemoteUIConnectionWizard API which is specific to the connection type
> 
> This workflow seems pretty confusing, possibly opening up two different wizards. I'm wondering if an alternative might be useful here.  org.eclipse.wst.server.ui has an interesting framework called "TaskWizard" which basically allows child pages (WizardFragment) to be added depending on selections on previous pages. It's very useful for making wizards with variable workflows, and can be seen in the Servers View via the New Server action.  The first page has a list of server types, and then loads the next 'fragment' dynamically based on the selection on the first page. It's probably about a half-dozen classes.
> 
> But it appears the current o.e.remote.ui API isn't very well suited for this if each connection type is making its very own wizard rather than simply pages (or wizard fragments as o.e.wst.server.ui does). Changing this would be a significant api change / breakage. But the current mechanism feels very clumsy.   I would consider making a patch for this, but I'm concerned such an API change may not be acceptable to you all.

The current design is primarily intended for using a single remote services provider. There is a preference that sets the default provider, then dialogs like the Remote Connection preference page, or widgets like the remote resource browser, use the default to avoid having the user select a provider before the wizard/widget is opened. If there is a new usage model where the user will be using multiple different providers, then I’m certainly open to ways of improving the user experience. I would also suggest opening a separate bug on this so we can discuss the design in more detail.

> 
> 
> 
> Finally, do we have dates we're targeting for each of the main changes that are upcoming? (connection view, terminal unification, remote fs browser, move of o.e.remote into tm, etc) ?

Doug has said this will be soon, but he has other work to complete first.

> 
> Thanks again to all who are involved. It's exciting to see a rejuvenated community, but we're still concerned we may need one more release of RSE before migrating our users to o.e.remote if possible. Is this at all feasible?

It’s certainly feasible for the Juno SR2 timeframe. I don’t see any real obstacles for keeping RSE around in Mars, but that still needs to be agreed by the community.

Regards,
Greg