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

From Second Life Wiki
Jump to navigation Jump to search
 
(16 intermediate revisions by one other user not shown)
Line 7: Line 7:
Latha Serevi will host a discussion on the theme of "proxy-based interop".   
Latha Serevi will host a discussion on the theme of "proxy-based interop".   


=== Interop use cases relevant to proxy-based interop ===
== Interop use cases relevant to proxy-based interop ==


:# IRC and XMPP bridging
:# IRC and XMPP bridging
Line 19: Line 19:
:# 3d scene adapters across incompatible VW's
:# 3d scene adapters across incompatible VW's


=== Examples of proxy-based and other approaches ===
== Examples of proxy-based and other approaches ==


:# Proxies based on SL packets and libomv
:# Proxies based on SL packets and libomv
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?


=== The Problem with Proxies ===
== 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:
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:


# Users need a certain amount of networking awareness
:# Users need a certain amount of networking awareness
# 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
# Terminating the proxy kills or disables the viewer session
:# There can be only one proxy at a time, which limits flexibility
# Summary:  proxies won't catch on as a common user facility
:# Terminating the proxy kills or disables the viewer session


These problems severely hamper widespread adoption of the normal proxy approach.
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.


=== The Solution for Proxies ===
== A Solution to the Problem with Proxies ==


# Replace the inline proxy process by a transparent proxy thread in the viewer
There is a technical solution to the problems outlined above.
# The viewer would connect to the desired target world in the normal manner
 
# By default the proxy thread would be fully transparent and do nothing
:# Replace the inline proxy process by a transparent proxy thread in the viewer
# Proxy programs/scripts can be loaded into or unloaded from the proxy thread
:# The viewer would connect to the desired target world in the normal manner
# From a user perspective, the "problem with proxies" vanishes.
:# By default the proxy thread would be fully transparent and do nothing
# (Implementation detail:  either load proxy code into thread or attach via socket)
:# Proxy programs/scripts can be loaded into or unloaded from the proxy thread
:# From a user perspective, the "problem with proxies" vanishes.
 
Possible implementation options:
 
:# Either load proxy code directly into the proxy thread (fast but not robust),
:# 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.


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

Latest revision as of 08: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.
Retrieved from "https://wiki.secondlife.com/w/index.php?title=AW_Groupies_In-World_Meeting_Agenda&oldid=895413"