On 10/19/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> David Glasser wrote:
> > On 10/19/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> >> Hyrum K. Wright wrote:
> >> [snip]
> >>> Stefan proposed elsethread an API which allows consumers of
> >>> libsvn_client to see the server's capabilities. How would a GUI handle
> >>> that? Would you need to have additional user interaction, or just a
> >>> warning that the server isn't adequate, therefore the output isn't as
> >>> actuate as it otherwise would be.
> >> That depends on what the GUI uses the API for. If a client can ask the
> >> server what it can and can't do, that helps a lot when designing the UI
> >> and showing hints to the user.
> >>
> >> An example from 1.3.x days:
> >> the 'svn log --limit' worked with 1.3.x servers, but was terribly slow
> >> when done with < 1.3 servers because the svn library then would fetch
> >> the whole log (for the specified revisions) and just filter out those
> >> which were too much.
> >> If I could have asked the server with a (relative) fast call to an API
> >> first if the server could do the --limit, I could have changed the "Next
> >> 100" button behavior in the log dialog accordingly:
> >> * if the --limit was supported, fetch logs from lastfetchedrev to 0,
> >> with limit 100
> >> * if the --limit was not supported, fetch the logs from lastfetchedrev
> >> to lastfetchedrev-100
> >>
> >>
> >> I don't know why you care about *how* a GUI client would use such an
> >> API, because that's usually not really known before an API exists. All I
> >> can tell you is that such an API would be a big help: there are always
> >> such cases as I described above. And with such an API available, I'm
> >> sure I'll find other cases where I could make very good use of it.
> >>
> >> with the svn_client_suggest_merge_sources API, I would first check
> >> whether the server supports merge tracking.
> >> * if yes, use the svn_client_suggest_merge_sources API to fetch
> >> suggested source urls, then show those to the user in the merge dialog
> >> * if not, don't call the svn_client_suggest_merge_sources API and let
> >> have the user enter or select the source urls manually
> >> Because: without the server support for this, the
> >> svn_client_suggest_merge_sources API call is terribly slow and can't be
> >> called while initializing the merge dialog - it would simply take way
> >> too long.
> >>
> >>> The idea here is similar, except we use the error mechanism to
> >>> communicate the insufficient server version, instead of an explicit API.
> >> I don't like the idea of trial-and-error to find out whether the server
> >> supports something or not. Because that behavior could change without
> >> notice. I'd rather have a specific API to ask for that information.
> >
> > These aren't competing options.
> >
> > We would use the new capability API to implement a mergeinfo capability.
> >
> > If you want, you can check it first before making other API calls.
> > (Maybe this means we need to expose capabilities at the client level,
> > not just at the depth level.) But if you don't, the client lib should
> > check it and error out if it can't be supported.
>
> No, you misunderstand me. I don't want the library to *not* try the new
> capability API. All I want the check for is to know whether an operation
> is fast or slow. Because that's a very important thing to know - slow
> API calls can't be used in certain situations (the UI must be responsive
> and fast, no matter what).
> And because the client API silently works around missing server
> capabilities by doing sometimes *very* lengthy operations, I can't
> decide beforehand whether an API call is fast or slow.
That's exactly what I said. "If you want, you can check it
[capabilities] first before making other API calls."
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 21:52:10 2007