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

[Greg Watson <g.watson@xxxxxxxxxxxx>]

> On Jan 22, 2015, at 12:00 PM, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:
> 
>>> 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 ?

Yes.

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

The connection information is specific to the provider, so if you wanted to have a provider that used part ftp and part ssh, your implementation would need to handle supplying one set of credentials to both. If you then wanted to use a completely different provider, such as the JSch one, the user would need to supply another set of credentials, yes. I don’t imagine many situations where you’d need to share credential information between providers, since if they are using different protocols you’re likely to need different credentials anyway. But if this is a use case you think is likely, then I’d be interested in understanding it better.

Greg