From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Hanson Date: Fri, 14 Jun 2002 18:04:13 +0000 Subject: xhotplugd -- project idea Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Date: Fri, 14 Jun 2002 19:55:22 +0200 From: Tim Jansen On Friday 14 June 2002 16:34, Ilya Konstantinov wrote: > 2. Providing a way to run graphical (X) applications on HotPlug > triggers. xhotplugd would not provide a GUI, but only means for > applications to "register" a file to be executed upon a HotPlug event. Functionality like this is certainly needed and I would be insterested in helping to realize it. But you could probably also extend the the current hotplug script to communicate with GUI apps. What you would need is a script/program that can send events to the GUI apps, for example by sending information about the event to a named pipe. A daemon of the desktop environment could then listen to that pipe. The advantage of this solution is that a) you can base such an app on the current hotplug system and b) you do not depend on X11, it would also work for console/DirectFB/etc... I agree with this, although I think it doesn't go far enough. I think there's a need for a general event-signalling mechanism. This can be used in a number of contexts: hotplug events, apm/acpi events, network configuration, pcmcia. The advantage of doing it this way is that it provides a uniform signalling interface, therefore making it easier to modularize the signalling and handling code. This is as opposed to the current system, in which all of the event-signalling mechanisms have their own idiosyncratic interfaces, which nearly always are conventions for invoking shell scripts. This problem is particularly obvious in the context of laptop network configuration, in which there are many different packages, each of which is composed of several parts built into a monolithic program; if all of these programs used a standard event mechanism, they could be modularized and the end user to use each module separately, even mixing modules from different packages. I've designed and started implementing this mechanism, and plan to deploy it both for APM and for network configuration in Debian. The design is very general, and is based on sockets so that it can easily be extended to handle inter-machine signalling if that ever turns out to be useful. The protocol will be implemented on top of BEEP, so that it is easy to maintain and to secure. I'd be interested in discussing this further if anyone is interested. Although perhaps it's not really on-topic for this mailing list. Chris _______________________________________________________________ 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