[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: better status notification

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-11-11 20:18:52 CET

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> > 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.

Ah, so then, if we went this route, one of two things would need to be
true, because of the multiple pass issue:

  * the svn_client_status() would still need to construct a hash of
    status structures, but it would be totally private. As soon as a
    structure was deemed "fully mature", it could be sent back to the
    client via notification.

     -or-

  * svn_client_status() sends status information back to the client on
    the fly, with the understanding that it may send information more
    than once per path.

Are we still liking this? Keep in mind that this solution, along with
my proposal above, still requires that we do the network pass first,
which is a goodly bit of rewriting.

At the moment, I think I'm now shooting for the lowest-hanging fruit:
I've got svn_client_status() sending a 'status' notification back to
the client every time a statstruct is added to the hash. The client
currently has no information, other than the fact that some path was
statted. Still, this is enough information to show a procession of
dots, a spinning cursor, or a throbbing icon. Maybe that's all we
need for now -- just an indication that *something* is happening. We
can "enrich" the status notification system later on.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 11 20:20:57 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.