David Glasser wrote:
> 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."
How can we check this without such an API?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.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:58:48 2007