Difference between revisions of "AW Groupies In-World Meeting Agenda"
Jump to navigation
Jump to search
Latha Serevi (talk | contribs) |
Latha Serevi (talk | contribs) |
||
(21 intermediate revisions by 2 users 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 == | |||
:# IRC and XMPP bridging | :# IRC and XMPP bridging | ||
Line 15: | Line 15: | ||
:# Viewer UI enhancements | :# Viewer UI enhancements | ||
:## separable windows (SNOW-375) | :## separable windows (SNOW-375) | ||
:# Server-side rendering (?) | :# mix and match client features | ||
: | :# Server-side rendering (??) | ||
:# 3d scene adapters across incompatible VW's | |||
== Examples of proxy-based and other approaches == | |||
:# Proxies based on SL packets and libomv | :# Proxies based on SL packets and libomv | ||
Line 26: | Line 26: | ||
:# hypothetical VWRAP proxies | :# hypothetical VWRAP proxies | ||
:# Relay agents using multiple client-style connections | :# Relay agents using multiple client-style connections | ||
:## IRC bridging Latif's way (Radegast agent with plugins) | :## IRC and XMPP bridging Latif's way (Radegast agent with plugins) | ||
:# 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 (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
- IRC and XMPP bridging
- Enhanced world interactions
- Double-click TP (Par)
- Viewer ident (Par)
- Viewer UI enhancements
- separable windows (SNOW-375)
- mix and match client features
- Server-side rendering (??)
- 3d scene adapters across incompatible VW's
Examples of proxy-based and other approaches
- 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?
- Proxies based on SL packets and libomv
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.