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

From Second Life Wiki
Jump to navigation Jump to search
 
(29 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Next AW Groupies meeting:
Next AW Groupies meeting:


:: '''2009-June-2 0930 PDT'''
:: '''2010-May-4 0930 PDT'''


''(Agendas run over to the next week if one week is lost to a special event.)''
'''Please help fill in this agenda outline!  Don't be shy.'''


'''Please add your own agenda items here!'''
Latha Serevi will host a discussion on the theme of "proxy-based interop". 


# It has been about a year since the encouraging step #1 of "Gridnauts interop", ie. one-direction TP from a non-main SL grid to an Opensim instance.  Clearly step #2 is long overdue.  What would we wish step #2 to be?  Discuss.
== Interop use cases relevant to proxy-based interop ==


:: Some ideas for step #2, or for steps #2-5:
:# IRC and XMPP bridging
::# TP in the opposite direction, namely from an Opensim instance to the SL grid.
:# Enhanced world interactions
::# Allow these TPs to work with the SL Main Grid.
:## Double-click TP (Par)
::# Allow objects whose assets belong entirely to the TP'ing person to migrate during the step #1 TP.
:## Viewer ident (Par)
::# Implement the "interop bit" (in line with Philip's statements) to extend legal asset migration.
:# Viewer UI enhancements
:## separable windows (SNOW-375)
:# mix and match client features
:# Server-side rendering (??)
:# 3d scene adapters across incompatible VW's


::# implementation of a generic protocol for Agent Domain-based/mediated group IM and related issues.
== Examples of proxy-based and other approaches ==
::# generic service discovery for group IM and other OGP-specific services.


::If there is any consensus on a reasonable step #2, this could be taken to Zero's office hours at 1pm, same day.
:# Proxies based on SL packets and libomv
:## XMPP bridging Dahlia's proxy way
:## LordGregGreg's http://code.google.com/p/par/
:# hypothetical VWRAP proxies
:# Relay agents using multiple client-style connections
:## IRC and XMPP bridging Latif's way (Radegast agent with plugins)
:# Loosely coupled client UI components
:## SNOW-375 (Dzonatas), provides http interface to viewer/world state
:## 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:
 
:# Users need a certain amount of networking awareness
:# Viewer has to be directed at proxy instead of at the target world
:# Proxy needs to be brought up manually before the viewer
:# There can be only one proxy at a time, which limits flexibility
:# 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.
 
:# Replace the inline proxy process by a transparent proxy thread in the viewer
:# 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
:# 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 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.
Retrieved from "https://wiki.secondlife.com/w/index.php?title=AW_Groupies_In-World_Meeting_Agenda&oldid=895413"