Proxies as Components of VW Clients

[This page derives from the transient agenda page created for the meeting of AW Groupies held on 4th May 2010. The meeting was hosted by Latha Serevi on the theme of "proxy-based interop" --- see transcript.]

Interop use cases relevant to proxy-based interop

1. IRC and XMPP bridging
2. Enhanced world interactions
   1. Double-click TP (Par)
   2. Viewer ident (Par)
3. Viewer UI enhancements
   1. separable windows (SNOW-375)
4. mix and match client features
5. Server-side rendering (??)
6. 3d scene adapters across incompatible VW's

Examples of proxy-based and other approaches

1. Proxies based on SL packets and libomv
   1. XMPP bridging Dahlia's proxy way
   2. LordGregGreg's http://code.google.com/p/par/
2. hypothetical VWRAP proxies
3. Relay agents using multiple client-style connections
   1. IRC and XMPP bridging Latif's way (Radegast agent with plugins)
4. Loosely coupled client UI components
   1. SNOW-375 (Dzonatas), provides http interface to viewer/world state
   2. wouldn't a SNOW-375 style REST API fit nicely into a (thick) proxy?

Common Problems with Proxies

The GridProxy that is supplied with libOpenMetaverse is an excellent piece of technology, but long-term experience with it highlights that there are a few problems with the approach:

1. Users need a certain amount of networking awareness
2. Viewer has to be directed at proxy instead of at the target world
3. Proxy needs to be brought up manually before the viewer
4. There can be only one proxy at a time, which limits flexibility
5. Terminating the proxy kills or disables the viewer session

These problems severely hamper widespread deployment and adoption of proxies as a regular user facility for non-technical users. Technical users are inconvenienced by these issues as well.

A Solution to the Problem with Proxies

There is a technical solution to the problems outlined above.

1. Replace the inline proxy process by a transparent proxy thread in the viewer
2. The viewer would connect to the desired target world in the normal manner
3. By default the proxy thread would be fully transparent and do nothing
4. Proxy programs/scripts can be loaded into or unloaded from the proxy thread
5. From a user perspective, the "problem with proxies" vanishes.

Possible implementation options:

1. Either load proxy code directly into the proxy thread (fast but not robust),
2. Or run a listener in the thread and attach proxy plugins to it via a socket:

• This places the proxy process "on the side" of the transparent inline thread which funnels the traffic into and back out of the socketed plugin process.
• Any number of such proxy processes could be attached and processed in parallel.
• A proxy process could be killed at any time (or could fail and die through software error), and the viewer would continue working normally --- the proxy thread would become transparent again as soon as the socket is disconnected.