[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tm-dev] Questions about current refactor and 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.
and remote service ID is linked to the provider, right ?
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).
Just to be clear on what we are looking for:
We are looking to avoid having users to reconfigure multiple connections
for the same thing dependent on what set of eclipse plugins they have
installed.
i.e. the way I/we see it today with RSE - user goes and define a
connection called "prod-server" and this name and UI for remote access
files and connections can now be reused wether he is using it for
terminal connections, CDT deployments, WTP server deployments etc.
As I see the new proposals that kinda goes away since each will end up
with their own (this might be me completely misunderstanding the new
approach - I kinda hope I do ;)
i.e. if we wanted to add ftp support to TM could that be done without
requiring to enter yet another set of credentials/setup for the ssh
connection ?
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.
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.
Our issue is that for now there is no replacement for RSE in TM that
will be in place for us early enough to move to it and reliably release
on top of it for Mars.
Hence why my vote definitely is to keep RSE in Mars, add the new thing
as option to let the community migrate in timely fashion instead of
breaking it from one release to another.
/max
http://about.me/maxandersen