Greg Stein wrote:
> On Thu, Aug 14, 2003 at 06:42:07AM -0500, Luke Blanshard wrote:
> > Is there some reason you guys chose this format over something
> > standard, like http://path/to/repos;version/path/to/file?
>
> WTF are you talking about? How is that "standard" ?!! You use a
> feature of URIs, but that doesn't make it standard. The !svn form
> also uses standard URI formats. Please explain... am I missing what
> you're saying?
Sorry, didn't mean to ruffle your feathers! Of course your URIs are
legitimate -- it's just that the "special URI" thing seems more
complicated than necessary. It'd be great (IMO) to have a syntax that
was invariant. My reading of rfc 2396 leads me to believe that
path-segment parameters would be a "standard" way of accomplishing
this.
However, I'm convinced by the proxy issue below. Real life beats out
theory every day of the week.
> > I don't see the need for this "special URI" thing.
>
> We needed a whole slice of the URI namespace to contain the various
> types of resources that SVN needs. It isn't just "this path at this
> revision" resources that you're attempting to model above. We also
> need baseline collections, activities, VCCs, etc. There is a bunch
> of stuff and the parameterized URIs you're describing just wouldn't
> cut it.
I see.
> > ... The whole point of the embedded semis is that they aren't
> > escaped, and can thus be seen as special.
>
> Sure, but I think it would have been a bit harder to model the
> various resource types via parameters. The URI specification is also
> unclear on whether the parameters identify distinct resources, or
> whether they are intended as params to a single resource.
I think it can be inferred that the parameters may identify distinct
resources. For example, the algorithm given for handling relative
paths leaves the parameters in place (assuming you don't back up over
the segment that has them).
> I'm also a bit leery of URI params after getting screwed back in
> 1996 by proxies that didn't handle them properly.
This is the heart of the matter, I guess. Obviously clients that
didn't handle them properly can be ignored... but if there is a
significant deployed base of proxies that mishandle these things then
you need a kludge that actually works. No offense.
> In any case, the client cannot manufacture these special URIs,
> whether they reside under !svn or whether you use params. So the
> model that the server uses is actually quite irrelevant. Heck, we
> could switch to the param version tomorrow if we wanted. It even
> might be a good thing to do to knock it into people's heads they
> shouldn't write clients that presume certain URI formats :-)
Well, that may be true, but I believe the original purpose of this
thread was to establish an URI syntax that could be handed out and
relied upon for browsing. I'd like to be able to bookmark such an URI
and be able to go back next year and see the same version I saw today.
The problem with the special URI thing (and it's not a huge problem,
really) is that it can't be relied upon.
Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 14 16:25:09 2003