Re: User-level Tasks in Hotplug Scripts?

[Scott Cuyle Fritzinger <scottf med unr edu>]

Note: sorry for all the CC's. i've lost track of who is on what list. :P

> > > Is there anything wrong with the simplistic approach of having a demon
> > > listening on a socket? If you want it generic, you have to use generic
> > > means of communication.
> > You don't want to pass out permission to access your X server to anyone
> > who happens to ask for it (if you do, you've compromized everything,
> > or go down into compartmentalized workstation hell, someplace where we
> > went 10 years ago and found fundamentally painful).
> > So the issue is fundamentally one of authenticating
> > the configuration GUI's process to the X server to allow connection.
> There's no reason the listening demon has to be part of X, or is there ?
> An interrested user would start a task listening upon login.

The listener should definitely be left to the desktops, or as a background
process as login in the case of a non-X environment.

The hotplug backend might implement a generic configuration language.
We've done this with gPhoto by using some common widgets and it works
really well. we use it for configuration of camera settings (exposure,
lens modes, etc...). It supports menus, lists, radio buttons, text
entries, etc... all the standard widgets.

Perhaps it would all work something like this:

1) Desktop listener listens on a port/fifo/pipe/whatever...
2) User plugs device
3) Hotplug runs appropriate script ("init"). init would be whatever
hotplug does now.
4) Hotplug then runs script with "get_config" arg to retrieve the
configuration 'widgets' (written to stdout)
5) Hotplug then writes the configuration widgets to the
port/fifo/pipe/whatever, prefixed by a header that describes which device
this is for. For now, hotplug considers itself done.
6) User select settings, selects OK.
7) Desktop listener writes the updated configuration widgets to the
port/fifo/pipe/whatever
8) Hotplug then reads in the updated configuration widgets, then calls
the appropriate hotplug script with "set_config" arg (config items are
read from stdin).
9) Hotplug script handles the rest.

Now, if multiple hotplug scripts try to claim a device, perhaps hotplug
will write a configuration that lets the user select which script to use,
and then it continues with the chosen hotplug script. This is something
that came up when i brought this up earlier: what if jphoto and gphoto
both want to use the device? just let them run, or let the user decide? if
there is no listener, then perhaps they all should run. if there is a
listener, let the user decide.

security? make sure you only accept connections from a user who is locally
logged in (not remote), unless you configure it differently to allow
remote connections. this just needs to be developed further in a USB
security model. (local user = full permissions on all USB devices?) :P

-=Scott Fritzinger
  The gPhoto project
  www.gphoto.org