Joshua Bell wrote:
> On Tue, Apr 20, 2010 at 5:16 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
>   
>> I think what was proposed by "What's *not* in VWRAP" is to establish a
>> default capability-to-scheme map, which would vwrap implementation to
>> proceed without full flexibility of other possible schemes per capability.
>>     
>
> Jeepers, I hope not!
>
> In a nutshell, the presentation said:
>   

Thanks for the clarification. I was a bit confused. (As I missed to type 
"which would allow a vwrap impl...", my bad.)

> * Maybe, if they do need to be standardized, the minimum necessary for
> interop might be e.g. as URLs pointing at human-readable Web pages -
> e.g. when connecting to a world you could be given a mapping of
> {'search': 'http://search.thisvirtualworld.org', 'map':
> 'http://map.thisvirtualworld.org' } or some such. I dunno.
>   
This is the basic idea behind ihave/sendme. I think others were 
concerned about extensibility on this idea when they heard "minimum," 
and I think that concern confused me a bit with their reaction. If I 
didn't apply the use-case of 2 separate programs on the client end (as 
with SNOW-375) that talked to a single server then I probably would 
worry more about extensibility then the 'minimum.' Between a single 
client program and a single server there are many assumptions that can 
be made, and those assumptions can include extensibility (which was 
demanded). With two programs on the client side, one might be 
'extensible' and the other might not be. My concern centered on what 
would need to be the greatest set or the least common capabilities in 
such use-case. One program can handle the inventory while the other can 
handle the scene, for example.

Right now, SNOW-375 expects a single peer, and that peer has an option 
to message with other peer programs, so there could be even more 
programs, like another for the world map, etc. A peer program may want 
to tell the viewer that a capability is actually a plugin to the viewer 
rather than being routed to through SNOW-375. That plugin then may 
message the peer directly rather than go through SNOW-375 (being routed 
through the viewer). I know this possibility has been talked about, yet 
I haven't seen other potential implementations mentioned yet in order to 
show there was significant consider of "minimums." Where I am at today 
with SNOW-375 has this potential with its flexibility of being 
peer-agnostic.

I think in this use-case, the web-page you idealize above is/could-be 
actually handled by the peer program(s).

> * So... don't assume XYZ will be done the same way that LLLP does it,
> or that XYZ even needs to be in VWRAP
>   

Currently, the peer program(s) just route everything through the viewer 
to figure out which path is needed between capabilities and LLLP.


> * But if you believe that XYZ *is* necessary to specify for interop
> and should be part of VWRAP, then the onus is on you to advocate for
> it by writing specifications and providing implementations!
>
> There was also an aside in the presentation that pointed out that
> VWRAP will require transport(s) with a variety of characteristics
> (reliable/RESTful, reliable/streaming, unrealiable/streaming) and that
> investigation needs to be done, as is called out in the WG charter.
>   

There is an obvious (and actually needed) potential to not route 
everything through the viewer either for performance reasons or just 
because the scene renderer really doesn't need to process unrelated 
scene information. I understand this was some of the initial motive on 
the server side, so that a sim doesn't have to process everything 
unrelated to its scene, yet it can let it's peer programs do the work by 
capabilities (with a more direct connection to the viewer). I think a 
part of the design and implementation that founded vwrap has relied on a 
many-to-one relationship with lldp/capabilities-to-viewer, respectively. 
Now the "minimum" requires a more many-to-many relationship, where the 
server needs to know the capabilities of the client-peer programs, like 
how the viewer needed to know the capabilities of the server-peer programs.

As I listened to the general conversation, others seemed to understand 
the modularity, yet some thought that any mention of 
many-to-many/server-to-client relationships meant support of a specific 
UI or for vwrap to support a specific UI, yet we know vwrap is about 
what needed to get that information to-and-from the specific UI, and it 
is not about the UI itself. (We, likewise, wouldn't want to say that a 
working implementation of vwrap on a certain sim isn't actually about 
the sim itself.)

One of the needed performances is movement-input and related animated 
feedback. The performance I have noticed so far requires an optimal 
route for this particular dance, which means a specific capability and 
scheme. Reliable/RESTful is optimal enough for this basic set, yet as it 
is currently being routed through the scene renderer it has the 
potential to delay noticeably. In another example, 
mouse-events/look-at-xyz would be overkill for a RESTful messages and 
would need more of a unreliable stream to preform smoothly. It could 
route the stream through the viewer with a udp scheme/capability, yet it 
would be more wise to have the viewer just tell the peer program to 
route the peer's mouse-event/look-at-xyz  stream more directly to the 
sim/server.

Of course, another possibility is to have the scene renderer route 
everything as a peer through a main client program (that handles 
mouse-events) rather then the other way around. Either way, the main 
client program acts a proxy to the rest of the peer programs and/or 
plugins under the many-to-many "minimum." In short, the proxy may just 
want to tell the peers to "do-it-yourself" and pass them the uri to do 
just that.