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

["Max Rydahl Andersen" <manderse@xxxxxxxxxx>]

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