On Wed, Oct 1, 2008 at 3:08 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On Wed, Oct 1, 2008 at 11:48 PM, Ben Collins-Sussman
> <sussman_at_red-bean.com> wrote:
>> On Wed, Oct 1, 2008 at 2:38 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>
>>> This is great. Only one thing I'm missing what is the reason to use
>>> repository root and encode path parameter in query args? From my point
>>> of it's much better to work on target URL, without knowledge of
>>> repository root. I mean:
>>> GET /repos/trunk/foo.c?cmd=get-file&r=23
>>> instead of
>>> GET /repos?cmd=get-file&r=23&path=/trunk/foo.c
>>>
>>> Because resolving repository root takes additional workaround unless
>>> we have working copy.
>>
>> ? I don't understand. Who has to 'resolve' a repository root?
> (sorry for my english)
>
> I meant that serf often resolves real repository root using
> svn_ra_serf__discover_root() and then requests some properties like
> repository UUID only on root of repository.
In the new system, svn_ra_serf__discover_root() wouldn't need to do a
bunch of PROPFINDs, it could just do a single GET
/repos/path?cmd=get_repos_root
>
>>
>> I'm focused on aligning our HTTP requests exactly with RA apis.
>> Every RA api takes an ra_session object which represents the 'root' of
>> a repository operation. Granted, it's not necessarily always the root
>> of the repository,
> "The administrator makes an svn repository available at a specific
> URI, which we'll refer to as the "repository root URI"."
>
> Sorry I was confused with term "repository root URI" in design notes
> which is actually "session root (anchor) URI". Maybe you'd like to
> change term in design notes to prevent such confusion.
Will do. I'm busy refining the doc right now.
>
>> but I think we should preserve the same concepts.
>> The HTTP request should be against a URI that matches whatever
>> ra_session is anchored on; if a &path parameter is present, then it
>> should considered relative to the anchor.
>>
> I'm OK with this approach if root URI don't have to be root of repository.
>
> I see only one minor problem: the same data can be accessed from different URIs:
> GET /repos/trunk?cmd=get-file&r=23&path=foo.c
> or
> GET /repos?cmd=get-file&r=23&path=/trunk/foo.c
>
> It could make testing/debugging of server-side harder, because will
> have to care about all cases every time.
Actually, gstein just persuaded me (in IRC) to never have a &path
query parameter -- it's too weird and "un-URL-ish".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 23:19:15 CEST