Bug 186315 - [efs] RSE EFS provider URIs should support disambiguation of multiple connections to the same host
Summary: [efs] RSE EFS provider URIs should support disambiguation of multiple connect...
Status: ASSIGNED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: Martin Oberhuber CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
: 205455 219258 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-05-10 04:45 EDT by Martin Oberhuber CLA
Modified: 2012-11-19 04:50 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-05-10 04:45:06 EDT
In RSEFileSystem#getConnectionFor() the RSE EFS Provider does:
        con.getHostName()

Note that this uses the IP address of the host. It has the advantage that if you have multiple connections to the same host you can take the one that is connected. But the disadvantage is, that multiple such connections can resolve to different file systems.

EG an ftp connection to dev.eclipse.org returns some completely different file system than an SSH connection to the same host. Also, hosts which do not use 
TCP/IP can have the host address empty.

I think it would be better to do con.getHostAlias() since this is known to exist and be unique. It is a more understandable, cleaner solution to explicitly reference a particular connection by name. This would also make the code below
if (isConnected) unnecessary since there can only be one such connection
with the given name.

An alternative would be to do URIs like this:

rse://129.81.18.123/path/to/file.txt?connection=FTP%20only
rse://129.81.18.123/path/to/file.txt?subsystem=Sftp%20files

putting the address into the URI's host field and the connection alias as an optional addition such that it can be disambiguated in case there are multiple connections to the same host. But this still wouldn't fix the issue of custom connections that do not have an IP address because they use very different kinds of transport.
Comment 1 Martin Oberhuber CLA 2007-09-12 17:06:31 EDT
I think I'd prefer the optional fragment for disambiguation.
Deferring to 3.0 and/or 2.0.2
Comment 2 Martin Oberhuber CLA 2007-10-05 04:54:13 EDT
*** Bug 205455 has been marked as a duplicate of this bug. ***
Comment 3 Martin Oberhuber CLA 2008-02-18 05:26:01 EST
*** Bug 219258 has been marked as a duplicate of this bug. ***
Comment 4 Martin Oberhuber CLA 2008-09-16 15:51:31 EDT
Bulk update of target milestone
Comment 5 Martin Oberhuber CLA 2010-02-26 19:10:43 EST
Bulk update of target milestones to 3.2
Comment 6 Martin Oberhuber CLA 2011-05-31 17:49:01 EDT
Bulk moving 3.3 deferred items to 3.3.1