Re: RFC: a permanent svn-specific URL syntax

On Wed, 2003-06-04 at 10:48, Bruce Atherton wrote:

> A simple URL, yes. But why insist on a query string? There are other ways
> of accomplishing the same thing.
>
If they accomplish the same thing, fine. I'm just concerned that the
other ways will require custom ways of writing authentication schemes,
something that may delay the ability to implement them for quite a while
longer.

>
> >Again I see your point, but I'm coming at this from a user perspective,
> >not a developer perspective.
>
> As a user, how is this:
>
> http://my.svn.org/project/branch/file.c?rev=1010
>
> different from this:
>
> http://my.svn.org/project/branch/file.c;rev=1010
>
> The first says that the resource is "file.c", and that a query is applied
> against that resource. The second says that the resource is "file.c with a
> parameter of rev=1010".
>
But this isn't necessarily the case.

http://my.svn.org/project/branch/file.c?rev=1010
 
might refer to a resource named file.c--but it's possible that the
resource is actually /project/branch, or even just /project. In my Team
Checkin site, for example, if you go to
http://teamcheckin.com/game/fiddlers/?gameID=59, what is the resource?
Trick question--the script that is running is /game. The /fiddlers is
parsed into a query for the database, the ?gameID=59 is used as the time
value, which I can provide using either GET or POST. In Perl and PHP,
you can get at the /fiddlers/ part by using the $PATH_INFO server
variable that Apache passes to the script when it finds that /game is a
script, not a directory. Now I don't know if this is technically
correct--all I know is our soccer team kicked butt Monday night.

But by making /fiddlers appear like a resource, it greatly simplifies
access control.

My concern with

 http://my.svn.org/project/branch/file.c;rev=1010

is that I can't control access to the previous version of resource
file.c without specifying each and every rev in my <Location> block.
Whereas by putting it in the query string, Apache ignores it.

>
> Of course. That is why using a semicolon makes sense. It is already part of
> the RFC for URLs (as I quoted previously) and it does not abuse the query
> string by using it in an incorrect way.
>

Okay. I admit my ignorance of the standards. I'm a practical kind of
guy--I just want it all to work. Standard or no, does the semi-colon
syntax work with access controls that exist today? If so, I have no
problem with it--just never seen it in use.

I still fail to see why this is an abuse of the query string, though. I
understand your point about the revision being the primary resource (and
I agree that that's how it should be, and one of the reasons
Subversion's better than CVS), we're just arguing semantics of the URL,
and my point is that there are lots of precedents for the syntax I
propose, whether it's correct or not, while I haven't seen the syntax
you propose.

Now everyone knows the world revolves around me so we should do it my
way ;-)

No, seriously, I understand that Subversion strives to comply to the
RFCs, and that from a data modeling standpoint, your suggestion may be
more accurate.

I'm just saying your way involves implementing something that doesn't
integrate well with how people would want to USE this feature in real
life, at least as far as access control is concerned--and what I'm
voting for is a shorthand with widespread use (correct or not) that
should be fairly straightforward to implement (okay, implementation is
probably a wash here), and uses the existing behavior/expectations
already set by svn update.

I love a lively debate. I'll yield if you can show me how I might
implement granular access control (both commit and update) using my
choice of Apache authentication modules on the day this feature were to
become available...

Cheers,

-- 
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