Difference between revisions of "AW Groupies In-World Meeting Agenda"
Jump to navigation
Jump to search
Latha Serevi (talk | contribs) |
|||
| (10 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 == | ||
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: | ||
| 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 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 | ||
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. | 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. | ||
== Solution | == A Solution to the Problem with Proxies == | ||
There is a technical solution to the problems outlined above. | There is a technical solution to the problems outlined above. | ||
| Line 54: | Line 55: | ||
Possible implementation options: | 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.