Ben Collins-Sussman <sussman@collab.net> writes:
> Hmmm, that's not how I interpreted it. I don't think we need to go so
> far as eradicating the returned-hash from svn_client_status(). I mean
> yes, we *could* do that, but then it means that the notification
> callback *must* return a status structure. That's pretty yucky.
The callback doesn't have to return a structure, it just has to return
or store the relevant information somehow. That is, the notification
baton could include `statushash'. (Or is that what you meant? In
which case, it doesn't seem yuck to me, actually it seems pretty
simple.)
> We've been trying to keep our notification callback very simple.
We were? (That thing doesn't look particularly simple to me :-) ).
But anyway, there's no reason there has to be one notification
callback, that's just the way it is now. We can pass a completely
different callback to svn_client_status() than we pass to other
things. As long as svn_client_status() documents the notificationn
semantics.
Looking at the signature of `svn_wc_notify_func_t', I think it might
actually be sufficient for status operations already. A custom baton
would be needed of course.
> Instead, a client should have many options:
>
> 1. just use the full hash when it comes back, ignore notification.
>
> 2. just use the notification callback, ignore the full hash.
> (as I mentioned earlier, it can still retrieve status-structures
> if the statushash lives within the notify-baton.)
>
> 3. Do some combination of both: use notification to make a cursor
> spin, and then sort the final hash for display.
>
> I think this is the most flexible.
Look at it this way: the input side of the notification interface has
to be the same in both plans. The only question is whether the
"owner" of the notification callback (that is, the client) has to
store information in a statushash itself, or whether
svn_client_status() has to do that and then return the information to
the client, even though it *already* sent all that information via the
notification callback.
For those clients using option #2, all of that code in
svn_client_status() is wasted. Not that it's particularly hairy code,
but why send the same information twice? If the client needs a
summary, it can just keep track of what it received via the
notification callback.
Hmmm. But you know, I think I'm bikeshedding. Both ways work, there
are some advantages (simpler clients) to your way too. Go for it :-).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 11 19:59:27 2002