[tm-dev] Questions about current refactor and API

[Rob Stryker <rstryker@xxxxxxxxxx>]

Hi All:

It seems lots of work is afoot here in the new year, so I'd appreciate 
it greatly if someone could summarize the plans so far? As I understand 
it, the plans are as follows:

1) Bring org.eclipse.remote into TM repo
2) Unify terminals, most likely in TM (?)
3) add a remote File System browser (I assume similar to the one in RSE 
to browse remote filesystem? ie a view?)
4) The "Launch Bar" (Not familiar with this?)
5) Add a connections view

I'm a bit confused about a few things. RSE is in the tm repository, but 
we're essentially deprecating rse. Does this mean RSE is being removed 
from the repository entirely? Or just that you're tweaking your build to 
bypass the rse folder?

The reason this confuses me is if we're still going to building TM, and 
RSE is in the TM repo, what exactly is the incremental cost to ensure 
RSE gets built and put on an update site as well, even if not by-default 
included in Mars? Or is the overhead in having someone actually test and 
verify it functions properly?

Basically, our product is concerned about migrating to a 
still-in-progress fast-moving replacement for RSE, migrating users' 
workspace metadata, etc,  and we suspect it'd be very useful if we could 
still get a build of RSE for Mars, even if it wasn't included in Mar, 
and possibly migrate users after Mars when o.e.remote and TM are a bit 
more stabilized and we have time to handle such a migration.



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.

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.

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.

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?

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.

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.



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) ?

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?

- Rob Stryker, JBoss Tools