Jack Repenning <jrepenning@collab.net> writes:
> Why?
>
> I see why it would be cooler to do it without contacting the repo, but
> I don't see an absolute necessity. Whatever we do with this URL, once
> we've composed it, is going to involve contacting the repo (isn't
> it?), so we're not enabling anything so grand as disconnected work.
> We're talking about a performance enhancement, I guess: save one
> server round-trip during the set-up, before we start into something
> that'll cost at least one more. Is that so crucial that we'd rather
> have no solution at all?
Oh, nobody's talking about "no solution at all".
All I'm saying is that thing-in-the-middle solutions are undesirable.
There remains the whole class of thing-at-the-end solutions, which is
what I'm assuming we'll end up with (perhaps with '@@' as separator,
perhaps something else).
I assumed that was implied, since such solutions have been widely
discussed in this thread all along. Sorry if that wasn't clear.
As for why constructability is important: Wow, it seems really obvious
to me, no offense, but I'll try to articulate it here. I don't think
I'm going to be able to do justice to how fundamentally important it
is, though.
When a user has a clear and simple concept in their head (such as "a
path at a revision"), then it's bad for an interface to put an
obstacle between the concept and its concrete expression. There will
be all sorts of circumstances in which people know they want a path at
a particular revision. To force them to make an extra round trip
merely in order to *construct the request* would be extremely
annoying.
The issue isn't the technical cost of the network round trip (although
that's bad too). The greater evil is extra round trip *between the
user and the interface*. The person knows what they want, clear as
day, yet they can't ask for it in one question -- instead, they need
two: first, ask for this other thing, then use it to ask for the thing
they originally wanted. An extra token has been inserted in their
life, for no good reason (since other solutions are available).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 5 21:28:57 2003