This is a feature request.

As described in the forum post in this ticket's URL, the basic idea is to have a "proxy" mode/model for the "local" Slimserver so that connections to SqueezeNetwork (SN) (and perhaps other "alternate" Slimserver hosts) could be "proxied" through the local Slimserver daemon.

The primary benefits of this proxy model would be 
 1) to allow users' local Slimserver plugins to continue to function
 2) local Slimserver and home automation systems could retain "control" over local devices using SN

For instance, I have a Slimserver plugin that monitors when players are powered on or off. When certain players change their power state, my plugin will use a device attached to my Slimserver host's serial port to power up the amp used for that player. The problem I have is that when the player is connected to SN, it has no connection to my local Slimserver host, so my plugin cannot tell when the player is turned off (or on).

A "proxied" SN connection could be handled something like Internet Radio -- the user could left-arrow out of the SN menus and back to the local menus, then use the local RSS reader, browse the local audio library, etc. while still listening to SN content. When in the SN menus, any IR events would be "seen" by the local Slimserver first, so they could be acted on. Any text issued from SN would pass through the local Slimserver, so it would be accessible by the CLI. "Local" Slimserver plugins, the local Slimserver's CLI, the local Slimserver's web interface, etc., could be used to regain control of the device even when it's using SN. Local screensavers could be used with proxied SN connections.

Naturally, the current "direct" SN connection model should also be supported. Some UI and configuration decisions would need to be made regarding how users decide (at a server or player level) which methods would be allowed and how a device operator would choose between direct and proxied methods if both were allowed.

-Peter