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

[Doug Schaefer <dschaefer@xxxxxxx>]

Hey gang, sorry for the silence last week, I was busy with a new internal
project getting it off the ground. I¹ll start to turn some of my attention
back to my o.e.remote API proposals again this week. Hopefully I can
provide my thoughts on the questions on this thread. I still see
o.e.remote as a great opportunity to build a TM framework that will be
great for the community. I¹m focused on both a good API and a good user
experience. It¹ll be awesome :)

I¹m not going to comment further on RSE. I have never liked it but that¹s
just a personal opinion based on architectural and UX principles I hold
dear. As with all things open source, if the community still sees the need
for it and are willing to figure out how to keep it alive, then that¹s
great and it will live on. Choice is never a bad thing especially in this
case where I don¹t think they take away resources from each other.

And the same is true with the Terminal. I think I have an idea for a UX
that fits better with my plans for the o.e.remote UX and will pursue that.
If people want to use TCF Terminal, that¹s fine. The same should be true
for the old TM Terminal. This trying to force a single answer is probably
not the best thing for the community, especially for those who don¹t agree
with it :).

Cheers,
Doug.

On 2015-01-22, 2:00 PM, "Greg Watson" <g.watson@xxxxxxxxxxxx> wrote:

>
>> 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
>_______________________________________________
>tm-dev mailing list
>tm-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/tm-dev