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