Tracking whether a connection is alive

[Kay Sievers]

On Wed, Jul 14, 2004 at 12:24:35AM +0200, Kay Sievers wrote:
> On Tue, 2004-07-13 at 18:03 +0200, David Zeuthen wrote:
> > On Tue, 2004-07-13 at 17:47 +0200, Kay Sievers wrote:
> > > I want to discuss another approach here:
> > > 
> > > HAL keeps track of the locks and it's mandatory for the lock owner to
> > > respond with the "reason" of holding the lock, when asked for.
> > > The "reason" returned can be easily interpreted by the _user_ and the
> > > user can take the appropriate action to solve the conflict.
> > > (think of a CD burning application, that displays a list of all you cd-
> > > drives with a live list of current activity going on from other
> > > applications)
> > > 
> > > If the lock is released, the application is notified by dbus and can
> > > display the now idle device and let the user start the new job on it.
> > > It should also be possible to specify:
> > > "start burning CD after <locking app> has finished <reason>"
> > > 
> > > It would be really nice feature. (think of a device manager, that
> > > displays the current activity for all active devices)
> > > 
> > > What do you think?
> > > 
> > 
> > I think it's a nice feature, but I don't like forcing the application
> > holding the lock to respond.

What kind of applications you are thinking of? If they use HAL to get a
device lock, shouldn't they be able to watch for device changes(disconnect)
by async messages anyway?

> > this:
> > 
> >  1. When acquiring the lock the application MAY give
> > 
> >     - name of application, localised
> >       - "Nautilus CD Burner"
> >       - "Nautilus CD Brenner"
> > 
> >     - name of reason, again localised
> >       - "Burning disc DATA_20040713"
> >       - "Brennen platte DATA_20040713"
> >     
> >     and on the locked dev these are stored in info.locked.app_name and 
> >     info.locked.app_reason and these goes away when info.locked is FALSE
> > 
> > Does it make sense to make the name and reason optional? And should we
> > do a better job of localisation? E.g. is it sane to assume that all
> > applications run in the same locale? I think it is...
> 
> Hmm, what about HAL returns only a handle to the locking application.
> The asking application asks the lock-holding directly for the reason and
> the name. This way, the lock holder may return the info in the locale of
> the asking app?

The interesting part of providing the "busy reason" directly to other
applications instead of setting a property on HAL, is the ability to have
real time updates instead of a static string. It would be possible this
way, to let other applications know about the progress of a operation.

The other nice side effect is, that if the application is not responding
to the request or the "busy reason" does not make sense to the user, the
user can take the appropriate action. The static info string should be
provided for this case anyway, to identify the dead application.

Hmm, don't know if this will work. I'm just a bit excited about the
feature :)

Kay


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal