[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [PATCH + FEATURE] Automatic notification of hotplugged devices
From:       Kévin_Ottens <ervin () ipsquad ! net>
Date:       2005-05-14 15:59:56
Message-ID: 200505141800.01506.ervin () ipsquad ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Le Vendredi 13 Mai 2005 23:13, Jérôme Lodewyck a écrit :
> 1/ Which module should handle notifications ?
> For sure, it musn't be the backend, as we would write n times the same
> code.

That's why I'm against the patch proposed by Edwin...
On the other hand, I see technical reasons for not putting the code handling 
user notifications into another process/kdedmodule (mainly resources 
consumption)

> 2/ Which module should decide if the user should be notified or not ?
> Currently, the mediamanager has no way to decide this, and that's why
> medianotifier is started in HALBackend in Edwin's patch.

Well, using another process/kdedmodule monitoring the media:/ directory would 
be enough... You list media:/ and then wait for modifications (medium 
appearing/disappearing). It was my original plan... which had the advantages 
to be simple, clean and to easily switch to another URL if necessary (for 
example I plan to have system:/media/ listing media:/).

>         a/ the mediamanager makes the notification decision.
> For this purpose, the mediamanager has to infringe on the backend design to
> determine whether a device has been added on startup or not.
> A possible implementation of this would be to define member functions in
> BackendBase, (e.g startup_list).

Hmmm.... or the backend could signal when it has finished the first list.

> (you should have a clearer idea about 
> this, since it seems to me that this is what you suggested)

Well, it was more what I suggested if it was done by monitoring media:/ =)

> PROS :
>         - this factorizes the maximum amount of code & policy

Ack...

>         - this introduces new structures that may be useful in the future

Hmmm, not sure, which ones would be useful?

>         b/ the backends make the notification decision and advise the
> mediamanager.
> When a backend adds a medium, it tells to the mediamanager if the user
> should be notified.
> This is _very_ easy to implement, as one just has to add a bool do_notify
> argument to the function MediaList::addMedium (and possibly
> changeMediumState). As far as MediaList and HALBackend are concerned, this
> is almost a one-liner change.

Right.

> PROS :
>         - a notification decision by the backend might make sense. Let's
> imagine we
> would like to use HAL's properties to decide about notification (crazy
> example : notify for memory cards, but not usb sticks...).

Well, you know that I don't want to rely too much on HAL specific 
features... ;-)

> Also, the 
> LinuxCDPolling backend should for sure notify, whereas this is not clear
> for FStabBackend (notification upon device mounting doesn't really make
> sense...) - minimum amount of change

Just note that the FstabBackend also manage when something new is added 
to /etc/fstab. ;-)

I like this approach too, but it has a big drawback... The resulting behavior 
at the media:/ level can be different depending on the used backends. It's 
already the case in the way the HALBackend manages cdrom drives (which 
reminds me that we should surely discuss the possibility to add another 
state : cdrom_empty).

> hope I have been understandable this time !

Of course! :-D

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]