Subject: [vwrap] Follow-up from "What's *not* in VWRAP" presentation

From: Dzonatas Sol <[email-masked]>
Date: Tue, 20 Apr 2010 17:16:45 -0700

As I worked on SNOW-375 ( https://jira.secondlife.com/browse/SNOW-375 , 
a REST/HTTP api for the viewer ), I also looked at the slides from the 
presentation:

https://docs.google.com/a/lindenlab.com/present/view?id=0AfAytYlNCPECZGZ2M24yMl8yN2N0OGJueGNy&hl=en

There was some mention about what probably is better for http and what 
probably is better for udp, etc. I get the impression that a message 
queue is assumed to be a part of the server. If so, I think that 
influenced on what should and shouldn't travel through whatever channel 
by whatever protocol. It still seems open to change based on given 
solutions that implement any portion of vwrap.

With SNOW-375, I haven't implemented the resource paths specifically, 
yet there is a overlap in functionality with VWRAP. What that in mind, 
it seems plausible to use different protocols/scheme-identifiers, like 
"udp://host:port/...", "ftp://..." , or "sql://..." rather then hardcode 
expected this-way or that-way for different message types.

Let's say my program connects to the viewer and it provides a specific 
login process. As it connects through SNOW-375, it passes a capability 
list. I may want some messages to route through different paths and 
specify that at the connection. That specific connection message may 
contains this information (not specifically in this format):

capability-xyz = http://localhost:8080/abc/capability-xyz
capability-mno = http://localhost:8080/abc/capability-mno
capability-pqr = http://localhost:8080/abc/capability-qrp
capability-etc = http://localhost:8080/abc/capability-etc
capability-def = udp://localhost:8080/abc/capability-def
capability-ghi = udp://localhost:8080/abc/capability-ghi
capability-jkl = udp://localhost:8080/abc/capability-jkl
capability-stu = urn:lllp:legacy:stu
capability-vwx = urn:lllp:legacy:vwx

With the list above, the program can tell by connection rather to use 
one method or the other: 1) lookup capability identifier 2) return uri.

Unless I missed something in the VWRAP docs, that main difference I 
suggest above is for the implementation to be more sensitive to the URI 
scheme instead of expect a pre-mapped capability to a particular scheme. 
I did notice some philosophy and further work put into VWRAP to allow 
such possibility, yet it may have been left open for debate to actually 
require this sensitivity as a standard.

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.

This flexibility in schemes and capability lists reminds me of the old 
I-HAVE/SEND-ME uucp negotiations, which was very reliable between the 
many versions of programs to copy files back in forth. If you remember 
those days then you'll understand without further detail.

---

From: Joshua Bell <[email-masked]>
Date: Tue, 20 Apr 2010 17:31:45 -0700

> proceed without full flexibility of other possible schemes per capability.

Jeepers, I hope not!

In a nutshell, the presentation said:

* People ask "When is XYZ going to be included in VWRAP?"
* The Linden Lab Legacy Protocol has lots of cruft in the subprotocols
(there are more protocol message types for search than for scene graph
updates!)
* The VWRAP WG Charter outlines the things the WG is working on which
form the core of interop (see the charter)
* Maybe anything beyond that (e.g. search, world map, etc) don't need
to be standardized at all in VWRAP as custom protocols and/or content
types
* 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.
* So... don't assume XYZ will be done the same way that LLLP does it,
or that XYZ even needs to be in VWRAP
* 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.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 20 Apr 2010 19:05:03 -0700

> 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.)

> '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).

> 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.

> 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.