From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Tue, 05 Feb 2002 03:32:37 +0000 Subject: Re: User-level Tasks in Hotplug Scripts? 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 > Fundamentally, we have no convention right now for any client (root or not) > to connect to an X server except on initiation of the user (unless > the user is silly enough to disable authentication entirely. No single convention, no. And I don't know what's current, but I've certainly worked with systems where X11 desktop frameworks have one application registered in a network naming system, acting as an authorized intermediary for other clients. The other clients weren't allowed to directly contact users' X11 servers, but that intermediary either implemented or forked off components that _could_ do so. Who has a good summary of what current versions of Gnome and KDE do along those lines -- anything? I see /tmp/orbit-* files on my current Linux system, UNIX domain sockets rather than TCP ones. That makes me suspect at least Gnome doesn't yet have a widely interoperable solution of this type. > Certainly, I want no user intervention as much of the time as possible, but > also need a hotplug design which allows for user intervention at the > time of first use in cases where it may be necessary. The hotplug script > design needs to allow for this, even if it is not the usual case. I think it clearly does, though implementation is lacking. None of these problems is novel, all have been solved repeatedly by groups who've implemented desktop frameworks under X11. The transport choice gets political though: everyone has their favorite RPC-du-jour (often wagged by significant infrastructure tails). If there's no single standard yet, having the X session startup save a /var/run file with some daemon's transport address understood by the hotplug framework would suffice. For non-desktop systems, it could point to a remote sysadmin agent. The requests delivered there would not necessarily correspond to hotplug events. > And there is need to automatically run GUI based programs, even after > configuration (automatically downloading images off your camera, for > example). That's one of my canonical examples. Though when it's a webcam, not a still image camera, "downloading" means firing up the user's preferred video tool ... :) - Dave _______________________________________________ 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