Subject: Re: [vwrap] Status and future of the VWRAP working group

From: Dzonatas Sol <[email-masked]>
Date: Sun, 01 May 2011 18:33:06 -0700

In review of HTTPBIS (w/SPDY), TLS, and XMPP for forward-thinking 
cross-development with VWRAP, the one main concern I have with those and 
where I think VWRAP needs to focus is the language-agnostic approach in 
connections and transmissions. If we could move VWRAP more to the core 
and define default type system for basic data, then we can use the 
streams from the others to continue progress. The current complication 
to just add the others is how there is often allowances for JavaScript 
to control the connection or affect it in any way, which to me is 
similar to hardware-hacking (and easily breaks stream-ability, 
complicates batch queries, expects direct browser awareness, and more 
issues could be said we've known from real hardware-hacking).

Those JavaScript allowances obviously have had the web-browser viewpoint 
paradigm in place, and VWRAP has had the virtual world paradigm. The 
problem with virtual world paradigm is that from one VW to another VW is 
like reinventing-the-Internet. I think VWRAP needs to refocus the 
"world" paradigm to useful patterns to virtualize and "wrap" these other 
IETF & RFC standards within XML. I don't mean redo every scheme, yet 
there are obvious patterns in the other WGs (& RFCs) that can use 
capabilities as deployed and present in VWRAP (yet to be fully outlined) 
rather than reinvent protocols. VWRAP can use the streams, presence, and 
TLS possibilities of the other WGs (& RFCs).

As I have pointed out here: 
http://groups.google.com/group/spdy-dev/msg/2fe946257e157684
I continue to make the case/proposal for pivotal data. Imagine all 
queries being sent through a proxy (like with SPDY enabled) that then 
bundles (i.e. "wrap"s) up the data into a stream such as this basic flow:

<? barebones XML std built-in IETF DTD ?>
<XML><IETF wg="vwrap">
<TLS>AVATAR:furryA
<HTTP>GET ...</HTTP>
<HTTP>PUT ...</HTTP>
<HTTP>DELETE ...</HTTP>
</TLS>
<TLS>AVATAR:furryB
<HTTP>POST ...</HTTP>
</TLS>
</IETF><IETF wg="...">
...
<IETF></XML>

If you think of the above flow as batched for the proxy to perform on 
the agent server, then the http queries could be used to manipulate 
inventory for furryA and furryB. The agent server could host WebSockets 
that viewers connect to such that would have those actions processed and 
then further bundled into the above for the region server to preform. 
Those http queries can actually be locally done on the region server, 
which then avoids transmission of the queries. The responses can be 
further bundled in return to the agent server.
This basically projects the queries that would normally take place on 
the viewer sides into batches on the region.

It only looks complicated until you consider the proxy does the http 
queries instead of the viewer or browser. Follow this pattern to 
"virtualize" monolithic browsers and viewers. We can design local proxy 
that acts as the (local) agent service for the viewer/browser. As IPv6 
is fully in operation in June, we can use IPv4 clouds to be these 
proxies/agent-servers to the IPv6 world. The VWRAP enabled clouds adds 
purpose, not only to proxy, yet to stream, frame, and bundle queries 
between the IPv4 "region" and the IPv6 "region".

Some already consider "the cloud" as the avatar/asset teleport device in 
regards to virtual worlds.

Beside power consumption, one way I visualize these virtualization 
techniques is imagine your two robots/avatars on Mars and here on Earth 
you have a 3D surrounded room full of partitioned X-Windows and sound. 
There is a satellite as the proxy/agent-server. How can we use current 
protocols optimally to display here what is seen there? On top of that, 
add security for asset servers.

Of note, the charter shows June 2011 for "Digital Assets". We could turn 
some of those HTTP requests, in the example above, directly into DAEs. 
When the proxy receives any DAE, the asset is stored into the cache. 
When the browser/viewer requests that asset item, the local cache 
already has the item and the browser/viewer possibly does not need to do 
further queries to the Internet. Essentially, detangled the web.

On 04/30/2011 09:45 AM, Barry Leiba wrote:
>> That said, we need to be leading this discussion on consensus that can
>> be documented and posted. �And we need to focus on that and accomplish
>> it soon, for a vague but near-term value of "soon".
>>      
> We had a good bit of discussion in early April.  Now that we're at the
> end of April, and the discussions seem to have stopped for the last
> couple of weeks, I'd like a progress report.  Has there been any work
> on coming to consensus on the direction the group wants to take?  Any
> progress on consensus for the contents of an intro/overview document?
>
> Barry, as chair
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>    

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Morgaine <[email-masked]>
Date: Mon, 2 May 2011 05:54:26 +0100

Barry, I took some time today to re-read every technical item posted here
since your mail of March 23rd, and this is how I would summarize our recent
burst of activity:

   - It seems that there is significant unhappiness about LLSD, for a range
   of reasons.  Some are wondering why we are creating a new ADT rather than
   using an existing one like Protocol Buffers, while others are worried on a
   deeper level that LLSD is too rooted in SL legacy and gives us very little
   for the future.  (I did not voice an opinion on that subject in this round,
   but I have in the past expressed worries about LLSD extensibility.)

   - All discussions now seem to be taking multiple worlds into account,
   which is a huge step forwards for interop and should serve us well for
   document writing,  We are periodically giving assurance that "nobody is
   going to force you to interoperate", although that should really be obvious
   even to casual onlookers since denying interop is so easy.  Additionally, it
   is our stated goal to support all deployment patterns, and the walled garden
   is one of those.

   - We have ascertained that we are not "writing docs just to write docs",
   but only docs that reflect consensus.  Your description "tease consensus out
   of discussion and write it down" was very appealing.  We are still at the
   teasing stage, but I do sense a convergence coming.

   - An attempt was made to gain a priori agreement to always accept
   superset requirements in VWRAP, or to put it another way, to adopt a group
   mantra of "design for tomorrow".  I'm still not really sure whether it was
   the concept itself which attracted strong opposition (which I think would be
   most regrettable) or if the arguments were merely about choice of words.

   - Vaughn's wonderful protocol flow diagram kicked off an excellent
   discussion about protocol details.  This was (remarkably) the first time we
   had ever discussed the asset access protocol over these 2-3 years of work,
   and it led us to examine two very important issues: (i) eliminating the
   burden of capabilities when there are no access restrictions on an asset,
   and (ii) separation of assets into metadata and content.  This got us much
   closer to the real core of VWRAP than we have ever been, namely the asset
   services.

   - A previously unmentioned optional requirement appeared in the
   discussion:  simulation consistency.  Although optional, our protocol will
   need to allow it to be achieved (to the extent possible) when it is demanded
   by a region.

Given all the above (and many other things discussed in passing), I am not
at all unhappy with recent progress, and indeed it could be said that we
achieved more for interop in 2 weeks than in the previous 2+ years.  With
regards to writing documents, we're still teasing out the technical details,
but as we do this, our more general goals are starting to solidify as well,
so I think that an Intro doc will come in due course.

I do accept that this isn't happening very rapidly, but with so few bodies
assisting in the analysis, it's hard to do better.  Nevertheless, I think
that we are achieving something useful.

We may be even be close to condensing the recent discussions into a
paragraph or two, because full solutions are not needed for an Intro.

Morgaine.

=========================

On Sat, Apr 30, 2011 at 5:45 PM, Barry Leiba <[email-masked]>wrote:

> > be documented and posted.  And we need to focus on that and accomplish

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 03 May 2011 00:04:41 -0700

To further zoom in past to now, I wonder if we should generally revisit 
& predict IPv4 *.net addresses have code-behind/IL that can be cached or 
shared as assets, so we can assume to sandbox *.net when in doubt. 
Assume IPv4 *.com addresses have code-behind/script secured on site or 
certified for transience. Assume IPv4 *.org addresses are web-fronts, 
proxies, gateways, and legacy. License issues 'can be resolved', 
diplomatically, by use of *.org as transition from *.edu "graduation" vitae.

For virtualization, the significance here is XML element compression 
(with pattern kinetics and shared tokenization), which further means 
something to signal processors (or on the wire|stream|pipeline). Others 
may already have realized "what if there were already given common XML 
tokens for each TLD based on above" and even though the XML tag name is 
the same, the token value may differ for context (and precursorial 
types). If you follow, the differences in tokens values may act like 
pre-compressed interop states or less than volatile expect-states.

Hmmm....  think I avoided terminology of quantum-jargon, dynamic 
compilers, and trinary arithmetics in the above.

So I came up for a breath of air, and looked at http://test-ipv6.com/

...then wondered about the viewer in a browser, or browser in a viewer, 
and reviewed the above ideology again (and fell-back to "frames" 
possibility and windows "surface" probability).

--

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 03 May 2011 06:52:37 -0700

Meant to add some purpose to that last message: how to see overall 
current trends without the envelope of proprietary or institutionalized 
mechanisms, and identify region-agent transistions in media.

I did try to scrape people's simulated affinity of virtual worlds (if we 
re-charter); although, sim-usage is easier to explain and "play" with 
real-time concepts.

My front-end workstation is already encapsulated in 3D with current 
protocols, and I can't grasp why continue to put another system for 3D 
"awesome" simulation within another 3D simulation within the 3D viewer 
within 2D browser in a 2D window in the 3D monitor on a 3D network (with 
various protocols on protocols) in the real 3D world.

Thanks, I hope this is clearer.  More later....

On 05/03/2011 12:04 AM, Dzonatas Sol wrote:
> To further zoom in past to now, I wonder if we should generally 
> revisit & predict IPv4 *.net addresses have code-behind/IL that can be 
> cached or shared as assets, so we can assume to sandbox *.net when in 
> doubt. Assume IPv4 *.com addresses have code-behind/script secured on 
> site or certified for transience. Assume IPv4 *.org addresses are 
> web-fronts, proxies, gateways, and legacy. License issues 'can be 
> resolved', diplomatically, by use of *.org as transition from *.edu 
> "graduation" vitae.
>
> something to signal processors (or on the wire|stream|pipeline). 
> Others may already have realized "what if there were already given 
> common XML tokens for each TLD based on above" and even though the XML 
> tag name is the same, the token value may differ for context (and 
> precursorial types). If you follow, the differences in tokens values 
> may act like pre-compressed interop states or less than volatile 
> expect-states.
>
> ...then wondered about the viewer in a browser, or browser in a 
> viewer, and reviewed the above ideology again (and fell-back to 
> "frames" possibility and windows "surface" probability).
>

--

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 3 May 2011 07:14:11 -0700

oh. the reason people layer protocols in general is so we can re-use
the work done by others. like for instance, a lot of the old linden
VWRAP / OGP stuff used REST semantics to access data. we could have
written our own protocol on top of TCP, by why? HTTP had all the bits
we needed. there were several very good implementations already out
there, and firewalls will sometimes pass HTTP when they won't pass UDP
or other TCP protocols.

XMPP is also very interesting due to it's "event stream" semantics.

my hope was to specify a high-level abstract data / interface
description language (LLSD or DSD) and then produce "mappings" for
concretizing abstract data definitions onto several real protocols
(like HTTP, XMPP and RTP.)

though i'm not sure if anyone here is even interested in that anymore.

but the advantage of layering is you can create new services
relatively easily. you just create the abstract description of the new
service, and since you have rules for mapping the abstract service to
a concrete protocol, you're more or less done.

the alternative, embodied by the legacy linden UDP protocol (LLUP) was
to shove a bunch of data into a packet and require the receiver to
just know the structure and type details. this is not a way to produce
resilient products.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Tue, May 3, 2011 at 6:52 AM, Dzonatas Sol <[email-masked]> wrote:
> Meant to add some purpose to that last message: how to see overall current
> trends without the envelope of proprietary or institutionalized mechanisms,
> and identify region-agent transistions in media.
>
>> To further zoom in past to now, I wonder if we should generally revisit &
>> predict IPv4 *.net addresses have code-behind/IL that can be cached or
>> shared as assets, so we can assume to sandbox *.net when in doubt. Assume
>> IPv4 *.com addresses have code-behind/script secured on site or certified
>> for transience. Assume IPv4 *.org addresses are web-fronts, proxies,
>> gateways, and legacy. License issues 'can be resolved', diplomatically, by
>> use of *.org as transition from *.edu "graduation" vitae.
>>
>> For virtualization, the significance here is XML element compression (with
>> pattern kinetics and shared tokenization), which further means something to
>> signal processors (or on the wire|stream|pipeline). Others may already have
>> realized "what if there were already given common XML tokens for each TLD
>> based on above" and even though the XML tag name is the same, the token
>> value may differ for context (and precursorial types). If you follow, the
>> differences in tokens values may act like pre-compressed interop states or
>> less than volatile expect-states.
>>
>> and reviewed the above ideology again (and fell-back to "frames" possibility
>> and windows "surface" probability).
>>