0.5.8 goals and TODO list updated

[David Zeuthen]

On Tue, 2006-08-08 at 00:28 +0200, Kevin Ottens wrote:
> Le vendredi 4 août 2006 21:30, David Zeuthen a écrit :
> > Well, Lock() on drives is indeed meant to only be advisory. It doesn't
> > prevent anyone from invoking methods on the device - applications are
> > meant to be cooperative and that's fine.
> 
> Let me rephrase it this way then: I'd expect the polling addon to be 
> cooperative like any other application. Btw, I wonder about the use of Lock() 
> if it's not suitable for a case like this one... From your description below 
> it would be limited to a NotificationDisable() use.

I don't think sidelining applications and hal addons is a good idea.
Really, in many ways you should consider what the hal addons are doing
as part of the driver software - and for some instances (e.g. USB UPS,
ambient light sensor etc.) the addon _literally_ is the device driver.

It's about being specific - Lock() means "please don't invoke any
methods on the device object, I'm busy using it" while InhibitPolling()
means "please stop polling for media changes". These use-cases are
mutually exclusive.

> > (maybe we want to clarify in the spec what locking really means)
> >
> > And sometimes you do actually want polling to occur when holding a
> > lock... for example nautilus-cd-burner takes the lock on the optical
> > drive when asking the user to insert a disc. This happens because the
> > user might insert a rewritable disc with existing data on it and then we
> > don't want gnome-volume-manager to mount it. And to detect disc
> > insertion we need to poll.
> 
> Well, that's definitely a realistic use case. In this case it might be better 
> to have another couple of method to inhibit polling on devices having 
> storage.media_check_enabled == true. When inhibited on the storage device, I 
> would expect the polling to be inhibited for the subsequent volume devices 
> too.

We only poll on storage devices, never on volumes.

    David