Re: better status notification

On Mon, Nov 11, 2002 at 06:06:08PM +0000, Philip Martin wrote:
>...
> Just because the client gets notify callbacks in the wrong order
> doesn't mean it has to display them in that order. The command line
> client can accumulate the information supplied by the callbacks, and
> then sort it and print it when the svn_client_statuses call returns.
> A GUI client can decide to update the GUI with the information as it
> receives it, or to update some progress indicator and do post
> svn_client_statuses processing like the command line client. Give the
> information to the application and let the application make the
> decision.

This is kind of where I was thinking when I saw the first post on the
thread. But other people beat me to it :-)

However, I think the whole thread got into a rut based on the assumption
that the notification callback should *also* be the data delivery callback.
That is Just Plain Wrong(tm). :-)

Define a new typedef; something like svn_wc_status_delivery_func_t (eesh;
shorter name please!). The function takes a baton and a path and the status
structure. As stated, it may be called multiple times (or maybe just one
time?) The svn_wc_statuses() and svn_client_status() can take a func/baton
pair rather than returning a hash. The callback just throws the status item
into its internal hash.

The notification callback returned void *specifically* to avoid this kind of
"hey! let's add some code to the notification callback!" Bleck.

(that said, we did finally decide to return a boolean(?) to say "cancel the
operation"; or maybe an svn_error_t with a specific SVN_ERR_CANCEL_OPERATION
or somesuch)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org