Re: [vwrap] Some thoughts on Josh's Linden Lab Legacy Protocol discussion

[Richard Newhook <[e-mail]>]

David Levine wrote on 04/27/2010 05:41:55 PM:

> Now, this is doubly inappropriate for a programmatic approach. We neither

> want to make programs screen scrape for content cues, nor do we want to
> present them with a nice pretty user interface to manipulate. Thus,
> a structured data path would be desirable. More on thinking about how
> regions and scenegraph can expose APIs for performing tasks in a future
post

   I'd like to add some extra detail here to help explain the weaknesses to
using this approach a little more.  While it's tempting to feel that a
prepackaged UI component would eliminate a significant portion of
complexity, it makes some strong assumptions about the circumstances under
which it will be applied: capabilities of the consuming endpoint,
representational restrictions, etc.  The effect of each assumption that we
add is that we become more tightly tied to that exact situation described
by the assumptions, and more burdensome to those situations outside the
assumptions in order to integrate with us.

    One of the assumptions of the prepackaged UI approach that carries a
heavy burden is that the consumer of the service is a human.  Ultimately
that may be true, but the human part of the whole system is little more
than the tip of the proverbial iceberg.  If you look at most virtual
worlds, the human-to-computer interface (a.k.a "the client") is only a
small portion of the total infrastructure.  The rest consists largely of
back-end services and systems that keep the world 'turning'.  For example
(the quintessential SL world), there's presence services, money
transactions services, region simulators, message routing, backup services,
network monitoring....and untold many more.  These are the major consumers
of VW data, and practically none of them will benefit from a prepackaged UI
component.  If anything, the burden of having to untangle the data from the
UI will be a significant impairment to these services.

   The prepackaged UI component itself poses some assumptions that are,
quite frankly, unreliable at best.  It is conceivable that some
implementations of virtual worlds may not have a standard HTML rendering
component.  For example, mobile devices with extremely constrained display
sizes.  Or virtual worlds targeting the blind.  Or systems that act on
behalf of the user in a semi-autonomous fashion.  In other words, we'll end
up restricting the usefulness to a very specific set of circumstances, or
eventually see it mutating into a monster in the attempt of making it
useful to all circumstances.

   It'll also break the immersiveness/cohesiveness of third-party client
implementations, or it will affect the look/feel (think: other VW's logo
embedded in your own client), or it'll introduce a new security attack
vector into the client, etc etc etc.  You get the point.

   Perhaps, then, what we would do is approach the issue from a different
angle, one that permits the assumptions to be optional.

   For example, each service would provide the following:
   1) A definition of the service call, describing the methods, fields and
validation rules required.  Some of this is already in common use, via XML,
DTD.
   2) The service itself to perform the actions.  For example, SOAP or WSDL
services, JSON-based calls, etc.
   3) A working implementation of the service in HTML form (the
prior-mentioned UI component) that can be displayed and used directly.  Can
also be used as a living example of how to make use of 1) and 2) in a
functional implementation.

   This type of approach would both give an easy-out escape for those
clients that do not wish to deal with the messy details of the service,
while still accommodating those clients that have a need to get down in the
weeds of the service.


   Thoughts?



   Richard/
   Newfie Pendragon (SL)