Plugin Separate Process
Local Network Tap
A different approach that also looks quite interesting as it provides a lot of flexibility is to add just enough code to the SL client that it will forward all SL comms packets to a local network port and will accept packets to the SL grid but also to the view itself via that same local network port.
Plugins would connect to that local network port and get to see all packets. also, they could inject packets both for the grid as well as for the viewer.
Chat Tap
Alternatively, simply route chat between local scripts and applets and SL. An application would connect to the SL client and send a channel number. The client would route lines of text from that application to that channel in-world, and route chat on that channel (if possible) or instant messages starting with that channel number (so that a proxy script in an attached prim could relay the channel to the client) back to the program.
This would not be a general SL plugin, but it would give locally running scripts a mechanism to communicate efficiently with proxies in-world
Packet Format
A unicode-based, "human-readable" encoding of the packets would allow us to use almost any computer language known to AV-kind: a shell script could be a plugin! One suggestion is to use XML format. The XML format has several downsides, however, not the least of which is performance.
Plugin lifecycle
Plugins should only live for the duration of a session. A plugin starter in the client (in the worst case that could be done as a shell script wrapper around the SL client itself) that goes through a $HOME/.secondlife/plugin.d directory and starts all plugins in that directory in alphabetical order (00-plugin-1, 05-plugin-2, ...).
On shutdown the client will just send a "GOOD NIGHT" message out over the socket interface --- causing the plugins to shutdown.
Making life harder for attack scripts
We can make the port number random: the client (or wrapper script) picks a random available port number, passes that in to the secondlife client (if we are using a wrapper), and also as a startup argument to the plugins.
In addition, we can generate a randomized password for each SL session and pass that in to the client and plugins and it becomes rather difficult to run an JS XMLHTTPRequest attack...
Advantages
- Minimal code changes
- Very flexible: write your plugin in perl, python, java (fortran anyone?)
Disadvantages
- No filter: quite a bit of (local) traffic
- May be difficult or slow to create new UI using this method.
- Latency is a concern with user-interactive plugins, especially if something with a lot of overhead like XML is used.