linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: User-level Tasks in Hotplug Scripts?
Date: Tue, 05 Feb 2002 03:32:37 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-101288009010358@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-101256895903801@msgid-missing>

> 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

  parent reply	other threads:[~2002-02-05  3:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-01 13:09 User-level Tasks in Hotplug Scripts? Ryan Shaw
2002-02-01 23:58 ` David Brownell
2002-02-02 20:55 ` Jim Gettys
2002-02-02 22:02 ` Oliver Neukum
2002-02-02 22:12 ` Jim Gettys
2002-02-02 22:52 ` Oliver Neukum
2002-02-02 23:02 ` David Brownell
2002-02-03  0:58 ` Scott Cuyle Fritzinger
2002-02-03  8:36 ` Greg KH
2002-02-04  6:02 ` Dmitry Yu. Bolkhovityanov
2002-02-04 15:10 ` Jim Gettys
2002-02-04 19:28 ` Jim Carter
2002-02-05  3:32 ` David Brownell [this message]
2002-02-05 15:05 ` Ryan Shaw
2002-02-06 14:30 ` Marcus Harnisch
2002-02-06 14:54 ` Jim Gettys

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-101288009010358@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).