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:
>>>> 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?
>
> See the next sentence.
> "(Maybe this means we need to expose capabilities at the client level,
> not just at the [ra] level.)"
>
> Note that I meant ra, not depth :)
>
> We are in agreement I think...
In that case, we are :)
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 22:38:29 2007