On Tue, Aug 07, 2007 at 09:22:08AM -0400, Greg Troxel wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> 
> >> fnord gdt 244 ~/%co/SOFTWARE > gcodacon --debug 
> >> bad mariner command 'set:volstate                                                                    '
> 
> > That looks more like the reponse from an older venus (i.e. 6.9.1) when
> > gcodacon tries to enable the new state transition notifications.
> 
> I was more careful to run the right venus and now it works.
> 
> gcodacon fails to handle venus going away and coming back.  It seems to
> infinite loop when I kill venus (with vutil shutdown).  Ideally it
> should show a 'no venus' status, and reconnect when a venus appears.

It should do that, it uses the same reconnect logic as codacon. i.e. it
will set the state to NO_MARINER (i.e. venus dead), and tries to
reconnect about once every 5 seconds.

class MarinerListener: __reconnnect sets the state to 'disconnected' and
adds a callback to __connect after 5 seconds. This __reconnect function
is called whenever we get an IO error on the incoming socket, which
happens when venus dies, so unless we're not getting an error on the
select I don't see how it would get into a busy loop.

> It would be cool if the gcodacon display, and maybe the tray icon,
> showed the total # of CML entries.

I've mostly been running it on a well-connected desktop, so the # of CML
entries is mostly 0. Not sure how to show it in the tray icon, but the
trayicon tooltip/popup could probably show it,  we just have to store the
number of cmls in the internal VolumeList structure.

Jan