Re: xhotplugd -- project idea

[Ilya Konstantinov <anon1@future.shiny.co.il>]

On Sat, 2002-06-15 at 04:03, Tim Jansen wrote:
> On Saturday 15 June 2002 02:22, Ilya Konstantinov wrote:
> > That is why my proposal is to use an on-disk file for communications.
> > Don't worry - the disk buffering is effective enough to make the impact
> > of using the disk storage neglectible.
> 
> I would rather worry that it is more difficult to be notified about events 
> (you would need to mess with FAM, dnotify or something like this).

dnotify could be optional. stat()ing once in a while works great too.
It's not expensive really. With buffers, it won't even result in disk
reads.

> > Why not leave this daemon to be implemented differently by each desktop
> > environment? Because of the need to standardize Linux. 
> 
> Which functionality could a daemon provide beside X11 configuration (that 
> could be done inside X11 as well)?

The second functionality is launching programs on events. You cannot
launch X clients reliably unless you're an X client yourself (since
otherwise you don't have the same DISPLAY, the same XAUTHORITY; and
since you need to launch the registered app on every running X server).

Here I'm not sure whether it's better to have a single list or a
per-desktop environment list -- since programs to launch are commonly
tightly connected to the desktop environment. e.g. different "New device
is found" programs, different apps to handle digital cameras etc.

> I would prefer a library instead of another daemon running in background. Then 
> KDE could embed it as a kded module that uses standard C calls for 
> communication instead of a stand-alone process which communicates using 
> another RPC protocol. It would be important that the library can be 
> integrated into event loops though. 

In that case, I might imagine a different solution -- each desktop
environment can implement its own xhotplugd, which'll base its
USB-keyboard/mouse-to-model mapping on our configuration file (in
/etc/hotplug/) and otherwise work as they see fit.

The advantage in this method would be that the daemon could offer
configuration in a method standard for the given desktop environment.

The disadvantage would be that a KDE digital camera program couldn't try
to register itself for Camera USB devices unless its running under a KDE
xhotplugd, since it expects to talk to it via DCOP.



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel