TimothyB;188524 Wrote: > I thought that by using a custom .map on the server, one could pretty > much completely change what the remote buttons do. > > -- Timothy > (Also, I believe that someone has written a plugin that when his wife > turns the volume down, the server gradually cranks it back up again.)
I think what meant was not "Authorization" as in security, but as in Confirmation. There is no authentication or security in the slim protocol, but all remote presses are passed back to the server for handling, which is why you can do random things with the remote map. Therefor the server must confirm and act on any command sent via the remote. This is my understanding of how things work: remote key volume up -> squeezebox -> server -> map key to volume change -> send volume change update to the squeezebox. This is a very simple, lightweight, and synchronous design. The only disadvantage is that if there is latency introduced at any stage in the pipeline, say the slimserver is busy and does not respond to the keypress, UI is adversely affected. The CPU on the squeezebox is great, is has a very tightly controlled code base. The CPU in the slimserver is whatever the host machine has, and CPU time is not tightly controled, and the slimserver can be starved for resources. What this person wants is the volume control logic to be pushed into the squeezebox, and the slimserver is asynchronously updated of volume change events on the squeezebox. This would require a bunch more code on the sqeezebox to handle all the various configuration options that people have built into the slimserver.. fixed volume modes, analog disabling, etc. The protocol would also have to be updated to support async updates and conflict resolution. A user changes the volume on the squeezebox with the remote at the same time someone clicks "volume output is fixed" on the slimserver. You would need a millisecond timestamp sync between the server and the squeezebox(s) to determine which configuration would win. I'm not saying this is impossible, it's just a lot more work than doing sync updates to the device state. -- SuperQ ------------------------------------------------------------------------ SuperQ's Profile: http://forums.slimdevices.com/member.php?userid=2139 View this thread: http://forums.slimdevices.com/showthread.php?t=33695 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
