[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[tm-dev] Questions about current refactor and API
|
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