<br><font size=2 face="sans-serif">Stefan</font>
<br>
<br><font size=2 face="sans-serif">OK. I didn't pick up on the transition
from your original note which referred to URI's in general that end with
a "/" and a URI with an empty path, which is a special case I
think, in being considered to be equivalent to an <b>absolute </b>empty
path. But is this case really the one you were concerned about? A relative
path is not required to start with a "/" so inserting one would
certainly not be desirable. If this is the only case then I'm not sure
I have understood your concerns properly.</font>
<br>
<br><font size=2 face="sans-serif">If your issue is solely with the empty-path
case then I have no problem with a "/" being required, or being
introduced if omitted. However, I do still think that we would be best
served by an unconditional decomposition of all inbound URI's into the
elements that are described in the RFC, with the "path" (sic)
being decomposed into a sequence of segments. Even in this canonical form
the 1st "/" is clearly special and the fact of its presence needs
to be preserved.</font>
<br>
<br><font size=2 face="sans-serif">Also, are you concerned with incoming
URI's or outoing (OpenSim composed) URI's. I thought all inbound URI's
were coming through the HttpListener interface which I would have (naiively)
expected to have always used the underlying Uri mechanism.</font>
<br>
<br><font size=2 face="sans-serif">Sorry if I'm being dense here.</font>
<br><font size=2 face="sans-serif"><br>
Best regards<br>
Alan<br>
-------------------<br>
T.J. Watson Research Center, Hawthorne, NY<br>
1-914-784-7286<br>
alan_webb@us.ibm.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Stefan Andersson <stefan@tribalmedia.se></b>
</font>
<br><font size=1 face="sans-serif">Sent by: opensim-dev-bounces@lists.berlios.de</font>
<p><font size=1 face="sans-serif">09/10/2008 09:32 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
opensim-dev@lists.berlios.de</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif"><opensim-dev@lists.berlios.de></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Opensim-dev] Uris: Errors/Inconsistencies/TBD</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 face="Tahoma">Alan,<br>
<br>
I believe the Uri behaviour I'm talking about just concerns the host node.
What happens if you change that to<br>
</font><font size=2 face="Courier"><br>
Uri absURI = new Uri(</font><a href=http://localhost:9000/><font size=2 color=blue face="Courier"><u>http://localhost:9000/</u></font></a><font size=2 face="Courier">);</font><font size=2 face="Tahoma">
</font><font size=2 face="Courier"><br>
vs<br>
Uri simURI = new Uri(</font><a href=http://localhost:9000/><font size=2 color=blue face="Courier"><u>http://localhost:9000</u></font></a><font size=2 face="Courier">);</font><font size=2 face="Tahoma">
<br>
<br>
? I believe you should get the same result on mono.<br>
<br>
of course, if you specify segments, the uri should be reported back as
it was specified. Otherwise, Uri would change the semantics of the last
node. Which would be bad, indeed.<br>
<br>
I concur with your suggestion to use a uniform Uri strategy thru OpenSim.
I do believe that it should be built upon Uri and UriBuilder over home-grown
code. Given that I haven't found segment building support in neither, we
might want to combine Uri, UriBuilder and the uri building parts of RestClient
into our own OSUri class that encapsulates building and handling uris.<br>
<br>
The goal is, as I guess you state, to make the system as resilient as possible.
And, to some extent, to introduce a bit more fine-grained a typeset than
'string' for passing Uris.<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
Join the 3d web revolution : </font><a href=http://tribalnet.se/ target=_blank><font size=2 color=blue face="Tahoma"><u>http://tribalnet.se/</u></font></a><font size=2 face="Tahoma"><br>
<br>
<br>
<br>
<br>
</font>
<hr><font size=2 face="Tahoma"><br>
To: opensim-dev@lists.berlios.de<br>
From: alan_webb@us.ibm.com<br>
Date: Wed, 10 Sep 2008 08:07:47 -0400<br>
Subject: Re: [Opensim-dev] Uris: Errors/Inconsistencies/TBD<br>
<br>
</font><font size=2 face="sans-serif"><br>
Hi Stefan</font><font size=2 face="Tahoma"> <br>
</font><font size=2 face="sans-serif"><br>
The .NET behavior is bemusing. Running mono on Linux, the behavior is NOT
the same - which may be cause for even bigger concern. On Linux, given:</font><font size=2 face="Tahoma">
<br>
</font><font size=2 face="Courier"><br>
Uri absURI = new Uri("http://localhost:9000/abc");</font><font size=2 face="Tahoma">
</font><font size=2 face="Courier"><br>
Uri relURI = new Uri("abc", UriKind.Relative);</font><font size=2 face="Tahoma">
</font><font size=2 face="Courier"><br>
Uri simURI = new Uri("http://localhost:9000/abc);</font><font size=2 face="Tahoma">
<br>
</font><font size=2 face="sans-serif"><br>
then </font><font size=2 face="Courier New">Console.WriteLine(xxxURI) </font><font size=2 face="sans-serif">and
</font><font size=2 face="Courier New">Console.WriteLine(xxxURI.ToString())</font><font size=2 face="sans-serif">
both produce exactly what went into the constuctor. If I change the initial
string to have a trailing slash, only then do I see a trailing slash on
output. On the face of it I agree with your assertion that using the existing
behavior of Uri should be preferred, and yet if our goal is to obtain consistent
behaviour for OpenSim on multiple platforms, the tests above would suggest
that Uri is not going to do that for us, and that the RestClient code,
in doing things explicitly, is more likely to succeed. It would be nice
to get the same behavior from mono and .net, but that's probably much harder
to achieve.</font><font size=2 face="Tahoma"> <br>
</font><font size=2 face="sans-serif"><br>
I probably take issue with your criticism of the RestClient's (who wrote
this code - they should be defending this!) removal of a single trailing
slash. A single trailing slash is an accepted, if not entirely proper,
redundancy. Two trailing slashes would be an invalid URI in my opinion
and should always be rejected. As an externally supplied value we can not
adopt a pre-condition stance as to its validity, so testing and rejection
should be preferred I think. In the subsequent code that you used in your
example, given the preceding, then this IS based upon a slashless URL representation.</font><font size=2 face="Tahoma">
<br>
</font><font size=2 face="sans-serif"><br>
If I were writing the RestClient I think I would prefer to see the decomposition
of the URI into its component pieces, and reconstruction from that abstract
form immediately prior to use.</font><font size=2 face="Tahoma"> <br>
</font><font size=2 face="sans-serif"><br>
So my vote would be for a single class in OpenSim that provides a guaranteed
URI behaviour for everybody who deals in this area. No URI would be admitted
into OpenSim except via this class, and none generated from any other source.
All modifications to the URI would also be made using the class.</font><font size=2 face="Tahoma">
<br>
</font><font size=2 face="sans-serif"><br>
By the way, just so the original issue doesn't get lost, our objective
here is for OpenSim to have an HTTP interface (REST, XMLRPC, whatever)
that does not behave differently when a supplied URI has, or does not have,
a trailing "/", right?</font><font size=2 face="Tahoma"> </font><font size=2 face="sans-serif"><br>
<br>
Best regards<br>
Alan<br>
-------------------<br>
T.J. Watson Research Center, Hawthorne, NY<br>
1-914-784-7286<br>
alan_webb@us.ibm.com</font><tt><font size=2>_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
https://lists.berlios.de/mailman/listinfo/opensim-dev<br>
</font></tt>
<br>