Difference between revisions of "AW Groupies In-World Meeting Agenda"

From Second Life Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by one other user not shown)
Line 29: Line 29:
:# Loosely coupled client UI components
:# Loosely coupled client UI components
:## SNOW-375 (Dzonatas), provides http interface to viewer/world state
:## SNOW-375 (Dzonatas), provides http interface to viewer/world state
:## wouldn't a SNOW-375 style REST API fit nicely into a proxy?
:## wouldn't a SNOW-375 style REST API fit nicely into a (thick) proxy?


== Common Problems with Proxies ==
== Common Problems with Proxies ==
Line 38: Line 38:
:# Viewer has to be directed at proxy instead of at the target world
:# Viewer has to be directed at proxy instead of at the target world
:# Proxy needs to be brought up manually before the viewer
:# Proxy needs to be brought up manually before the viewer
:# There can only be one proxy at a time, which limits flexibility
:# There can be only one proxy at a time, which limits flexibility
:# Terminating the proxy kills or disables the viewer session
:# Terminating the proxy kills or disables the viewer session


Line 59: Line 59:
:::* 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.
:::* 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.
:::* 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.
:::* 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.


[[Category: AW Groupies]]
[[Category: AW Groupies]]

Latest revision as of 07:44, 4 May 2010

Next AW Groupies meeting:

2010-May-4 0930 PDT

Please help fill in this agenda outline! Don't be shy.

Latha Serevi will host a discussion on the theme of "proxy-based interop".

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.