Re: Proposal for reporting remote control button presses to userland

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Wed, 8 Oct 2008 13:05:40 -0400 (EDT)
"Jared D. McNeill" <jmcneill%invisible.ca@localhost> wrote:

> On Wed, 8 Oct 2008, Steven M. Bellovin wrote:
> > Seems reasonable (though I'm no fan of XML, and in any event think
> > that
> 
> Yes we know, you make it a point to say this every time somebody
> mentions using proplib. Deal with it or propose a better solution.

I try not to say it too often -- but see below...  In any event, this is
the substantive part of my comment on the XML:
> 
> > if we do use XML we should think hard about the actual data
> > returned -- envstat has far too much knowledge of what it's
> > seeing).

Why does envstat have lines like

        if (strcmp(sensor->type, "Fan") == 0) {
             stype = "RPM";  

Why does it need to know the units, hard-wired in, for every sensor
type?  Why does every sound card have its own set of names visible to
mixerctl?  (Why do those names seem to change periodically?  I almost
woke my wife recently when the mute button on my laptop no longer
worked, because mixerctl was configured to toggle the old name....)  We
don't want to need adaptation code in every program that wants to use
the data.

Sure, every remote will have its own peculiar buttons.  Lots of
functions, though, are common.  That implies a canonicalization layer
somewhere; I suggest that it be no higher than wsremoted and perhaps in
whatever feeds the mux.  (Perhaps we need two sockets, one for raw and
one for canonicalized data.)

As for the XML question: my preference would be a simple structure:

        struct timeval when;            /* Event imestamp */
        int remote_name;                /* Device */
        int button_name;                /* Button */
        enum direction;                 /* Press, release, ... */
        int value1, value2, value3;     /* For knobs */

If we are going to pay the price for XML, though, we should get the
benefit: include type information in the field.  This way, the
application can have less knowledge of the hardware quirks and be able
to act in a more device-independent fashion.

> Two concerns: first, can more than one application
> > connect to the daemon at once?  I hope so.  Second, is there going
> > to be some optional filtering, say by device?
> 
> Applications shouldn't speak to the wsremote mux directly, instead
> they should use the cooked socket provided by wsremoted,

Understood, which is why I wrote "connect to the daemon".

> in which
> case yes, you can have multiple listeners. The sample message I
> posted above has a 'source' key that you can filter on.
> 
Design question: should the receiver do the filtering, or should
wsremoted?  

                --Steve Bellovin, http://www.cs.columbia.edu/~smb