[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: a permanent svn-specific URL syntax

From: John Locke <mail_at_freelock.com>
Date: 2003-06-03 21:10:47 CEST

On Mon, 2003-06-02 at 09:37, Bruce Atherton wrote:
> At 09:58 PM 6/1/2003 -0700, Greg Stein wrote:
>
> > The ?rev=whatever form is not appropriate. The query string is
> > applied to
> > the resource specified by the other parts of the URL(*). i.e. it
> > implies
> > there is *one* resource receiving different query values. But that
> > isn't how
> > this stuff should be modelled -- we've got multiple resources. There
> > is one
> > for each revision. Thus, the revision number should be part of the
> > path
> > portion of the URL to get the proper modelling.
>
> I agree. I think the semicolon should be used, as that is specified by
> RFC 2396 as the way to specify parameters within the path component:
>

As a web developer, I disagree. As Greg states, the query string implies
that there is *one* resource receiving different query values. In a web
development setting, the "resource" might be a script that then goes to
retrieve different content based on the query string.

In fact, I'd argue that Subversion makes even more sense for using a
query string than most web sites--you have one resource (the file) with
a query string pointing to its contents at different revision levels.
Makes perfect sense, especially in a web server context.

-- 
John Locke
http://freelock.com
Recently published: "Extend the reach of users' email with IMAP"
http://www.techrepublic.com/article_guest.jhtml?id=r00620030507jxl01.htm
Play sports? Check in at http://teamcheckin.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 3 21:11:40 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.