On 01/04/2012 02:00 PM, Corey Ashford wrote: > On 01/04/2012 01:41 PM, Jeff Johnston wrote: >> On 01/04/2012 02:55 PM, Corey Ashford wrote: >>> On 01/04/2012 11:46 AM, Jeff Johnston wrote: >>>> On 01/04/2012 02:10 PM, Corey Ashford wrote: >>>>> Hi Jeff, >>>>> >>>>> I ran across an interesting problem with using the URI's that are >>>>> formed >>>>> in the linuxtools plug-in. I wonder if you have any thoughts on >>>>> this... >>>>> >>>>> We end up with URI's that look something like: >>>>> >>>>> remotetools://<connection-name>/<path-to-something> >>>>> >>>>> The problem that I ran into is that if I instantiate a URI object based >>>>> on one of these strings, I get a URISyntaxException thrown if the >>>>> <connection-name> contains any embedded blanks, or characters >>>>> other than >>>>> a-zA-Z0-9, hyphen, and dots. The syntax is defined by RFC-952 and >>>>> RFC-1123. RFC-952 states: >>>>> >>>>> A "name" (Net, Host, Gateway, or Domain name) is a text string up >>>>> to 24 characters drawn from the alphabet (A-Z), digits (0-9), >>>>> minus >>>>> sign (-), and period (.). Note that periods are only allowed when >>>>> they serve to delimit components of "domain style names". >>>>> >>>>> RFC-1123 relaxed the above rules, allowing up to 255 characters, and >>>>> allowing the first character to be a digit (so as to allow for IP >>>>> addresses). >>>>> >>>>> >>>>> It seems to me that there are a two solutions to this problem: >>>>> >>>>> 1) Create our own URI-like class that is more forgiving of the >>>>> characters in the "host" field. >>>>> >>>> >>>> I am definitely not in favour of this. >>>> >>>>> 2) Request that the upstream Remote Tools and RSE folks restrict the >>>>> connection names according to the above limitation (e.g. no embedded >>>>> blanks, etc.). My hunch is that this would be a no go. >>>>> >>>> >>>> This would be my take. If one cannot represent the name as a URI, then >>>> it should be restricted at creation time. I would suggest a bug be >>>> opened. >>>> >>>>> Any others? >>>>> >>>>> Have you run into this issue before? What do you think? >>>>> >>>> >>>> I have never run into the situation because all my host names are >>>> sensible (either http addresses or simple all-character names). I >>>> believe that should be the over-whelming majority of cases, if not 100%. >>> >>> Actually, if you create a Remote Tools connection, the default name is >>> "Remote Host" (notice the embedded blank). So if you don't change the >>> name, you get an error when you instantiate a URI based on this name. >>> >> >> Hmm, are we talking connection name or host name? The host name has to >> be a legitimate host to connect to. You presumably don't have a machine >> on the network called "Remote Host". > > Ok, I had assumed that Remote Tools and RSE formulate their URI's in the > same way, but apparently they don't (according to you and Greg Watson). > For Remote Tools, the connection name (not the hostname/IP address) > gets placed into the URI's <host> field. For example, if I leave the > connection name as "Remote Host", but specify a working hostname for > that connection, I get a URI that looks like this: > > remotetools://Remote Host/<path-to-resource> > > Note that the actual hostname is not encoded into the URI. > > For rse, I guess you get something like: > > rse://<hostname>/<path-to-resource>?connection="Remote Host" > > That said, when I use the file selector from RSE, it gives me a URI that > looks similar to the one used for Remote Tools. I need to look into how > I wrote the file selector for RSE to make sure that's not my error, though.
I have a follow up on this one. This is my error... I instantiated a URI based on the path that was returned from the browseFile method, a host based on the connection name, and no "query" containing the connection name at the end. URI selectedURI = new URI(scheme, connectionName, selectedPath, null); So we have the situation that Remote Tools and RSE really do use two different URI schemes. As an example, I created a project in ~/xnew on a remote machine (elm3b4.beaverton.ibm.com) using RSE and Remote Tools using the connection name "Remote Host". On RSE I get: rse://elm3b4.beaverton.ibm.com/home/corey/xnew?Remote%20Host Using Remote Tools I get: remotetools://Remote%20Host/home/corey/xnew I was able to use IRemoteFileManager.toURI() to fix the problem in my resource selector widgets. So unless I run into some other hang-up, I think this is a non-issue now. Thanks for your help! - Corey _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
