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

[Dzonatas Sol <[e-mail]>]

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.