Tracking whether a connection is alive

David Zeuthen david at fubar.dk
Tue Jul 13 09:03:44 PDT 2004


On Tue, 2004-07-13 at 17:47 +0200, Kay Sievers wrote:
> I'm just replying to my own post on the DBUS list, to move the topic
> over to this list, cause it doesn't require any dbus changes.
> 

Thanks for moving the discussion here.

> short summary:
>   There is the idea to add some functionality to HAL to get a exclusive 
>   lock on a device, to make sure, that no other application will perform
>   any action on it, while it is in use (cd burning).
>   David asked on the dbus-list how HAL can be notified of a dead
>   application, holding a lock and some sort of "alive? ping" was discussed,
>   but later rejected.
> 
>   http://freedesktop.org/pipermail/dbus/2004-July/001299.html
> 

Right, Havoc pointed out it's bad to ping

 http://freedesktop.org/pipermail/dbus/2004-July/001294.html

ie. we should fix broken applications.

> 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. Thinking a bit more about it, how about
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...

Cheers,
David


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



More information about the Hal mailing list