Subject: Re: [vwrap] Working Draft: SNOW-375

From: Joshua Bell <[email-masked]>
Date: Mon, 2 Aug 2010 10:53:36 -0700

On Sat, Jul 31, 2010 at 7:01 AM, Dzonatas Sol <[email-masked]> wrote:

> SNOW-375 is at a point to feature freeze and to fill-in development on
> whats already included. Icesphere (C# based client to Snowglobe & Second
> Life) uses SNOW-375 as a ReST based API. This shares concepts with VWRAP.
>
> Currently writing the resource dictionary, but here is an excerpt of
> documentation just put together:
>

Looking forward to it!

On the web page (
http://icyspherical.blogspot.com/2010/07/overview-snow-375-is-api-to-snowglobe.html
), you mention:

Payloads that contain nested XML structures may not work well with JSON, so
only LLSD is supported. This could be resolved with JSON specific queries,
yet Snowglobe would still internally have to convert LLSD to JSON, so that
would be an implementation detail on the transport layer.
<<<<

Can you elaborate here? Do you mean payloads that contain XML fragments,
where an XML document serialization would be more natural than JSON with XML
islands? Or...?

I'm a big fan of JSON despite the sparse types meaning it's not a perfect
serialization format for LLSD, and have been a heavy user of XML, so
understanding your issue is important to me.

Joshua

>
>   Overview
>
> SNOW-375 is an API to the Snowglobe code base to query reflexive
> information that affects Avatar, Agent, Assets, Inventory, Gestures, and
> other states of the client as it interacts with the virtual world. In order
> to enable the widest range of devices and scripts to communicate with the
> client, the API is language-agnostic. The flexibility of client-side
> scripting is a significant feature of SNOW-375.
>
> SNOW-375 allows for a multi-headed client architecture instead of a single
> monolithic design. There are many possibilities to this besides client-side
> scripting, like augmented reality devices, gesture recognition devices,
> social networking, advanced heads-up displays, integrated desktop programs
> (desklets), joysticks, machinima tools, and many more. Multi-headed clients
> are also significant, yet its transport layer may be platform dependent.
>
>
> Read more:
> http://icyspherical.blogspot.com/2010/07/overview-snow-375-is-api-to-snowglobe.html
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 02 Aug 2010 13:28:30 -0700

Joshua Bell wrote:
>
> >>>>
> Payloads that contain nested XML structures may not work well with 
> JSON, so only LLSD is supported. This could be resolved with JSON 
> specific queries, yet Snowglobe would still internally have to convert 
> LLSD to JSON, so that would be an implementation detail on the 
> transport layer.
> <<<<
>
> Can you elaborate here? Do you mean payloads that contain XML 
> fragments, where an XML document serialization would be more natural 
> than JSON with XML islands? Or...?
>
> I'm a big fan of JSON despite the sparse types meaning it's not a 
> perfect serialization format for LLSD, and have been a heavy user of 
> XML, so understanding your issue is important to me.
>
>

In such cases for XML, I currently assume that full secure 
encapsulation/canonicalization is needed to pass on sanity to non-XML 
formats. If we assume XML only, then one valid XML structure is directly 
implantable into another XML structure where allowed (ambiguous tags, 
variable DTDs, intra-tags). I don't see a way for JSON to support 
intra-tags.

I have written raw XML parsers that fold and unfold structures 
dynamically, and the parser knows nothing about its data or types. I 
could apply such technique instead of encapsulation.

When people say they don't like XML, I know they actually mean they 
don't like DTDs, which should have been a separate standard than raw XML.

--

---

From: Joshua Bell <[email-masked]>
Date: Mon, 2 Aug 2010 13:49:00 -0700

> variable DTDs, intra-tags). I don't see a way for JSON to support
Assuming I'm understanding you correctly...

As in LLSD, everything in JSON is a key or value. So you could easily have:

{ "somekey": "somedata",
  "otherdata": /* your data here */
}

... where the overall JSON payload's value is a map, and value of that map's
key "otherdata" is an arbitrary JSON value in place of the C-style comment
(the above is not valid JSON as written, of course). There is no capability
in JSON for the included data to change the meaning of the container, so
this is as "secure" as in a similar XML usage.

(If you had a buggy output mechanism that didn't output values as valid
fragments, then obviously the payload could render the container invalid.
But this is as true with XML as with JSON - or SQL or ... /me thinks of
little Bobby Tables http://xkcd.com/327/.)

I have written raw XML parsers that fold and unfold structures dynamically,
> and the parser knows nothing about its data or types. I could apply such
> technique instead of encapsulation.
>

Although a JSON parser must be aware of the JSON types (object, array,
string, number, true, false, null), it does not need to be aware of the
interpretation of the data any more than an XML parser that is not also a
validator. While this may seem slightly more complicated than XML (its just
tags, right?), a fully conforming JSON parser is simpler than a fully
conforming XML parser since XML is more feature-rich (whitespace rules,
attributes, character entities, CDATA, namespaces, mixed content, ids, etc).

So, although XML may be superior in other ways, I don't believe this is a
case where JSON is inferior to XML - if I'm understanding your point
correctly.

> When people say they don't like XML, I know they actually mean they don't
> like DTDs, which should have been a separate standard than raw XML.

In my experience, everyone has a favorite XML schema language, and thinks
the others are evil. :)

XML has a tremendous amount of power, but most of the time you need only a
small fraction of that power. (e.g. LLSD's XML serialization doesn't need
namespaces, mixed content, etc). Contrariwise, XML's expressiveness lets you
precisely serialize all of LLSD's types, whereas many LLSD types collapse to
JSON strings.

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 02 Aug 2010 14:44:35 -0700

Joshua Bell wrote:
> string, number, true, false, null), it does not need to be aware of 
> the interpretation of the data any more than an XML parser that is not 
> also a validator. While this may seem slightly more complicated than 
> XML (its just tags, right?), a fully conforming JSON parser is simpler 
> than a fully conforming XML parser since XML is more feature-rich 
> (whitespace rules, attributes, character entities, CDATA, namespaces, 
> mixed content, ids, etc).

Only attributes is part of raw XML, everything else you mentioned above 
is based on DTD. When you say XML parser without a validator, the above 
sounds like you don't mean raw XML.

>
> In my experience, everyone has a favorite XML schema language, and 
> thinks the others are evil. :)
Raw XML has no schema other than where to delineate.

>
> XML has a tremendous amount of power, but most of the time you need 
> only a small fraction of that power. (e.g. LLSD's XML serialization 
> doesn't need namespaces, mixed content, etc). Contrariwise, XML's 
> expressiveness lets you precisely serialize all of LLSD's types, 
> whereas many LLSD types collapse to JSON strings.

I count only 3 characters that a raw XML parser needs to know to do one 
forward sweep and perfectly index the entire structure. 4 characters if 
you want the sweep to give a nested index.

There is no secret about that. It's part of the published standard. Even 
the built-in XML parser to C# understands that. Hidden treasure? =)

Actually, I like the XML Parser of System.NET since it's easy to write 
code that gives a very detailed stack trace (when wanted) based on every 
tag, how to expect content, and how each tag should close. Look at my C# 
Snowglobe.Scalar class to see how I have split out each tag to a 
different function. It's makes it very functional and easy to group 
documentation in the source rather in the XML. Raw XML has always meant 
to exist for such usage.

DTD is just more formal "human readable," but not as "machine readable" 
as originally described by XML. The DTD was really only meant to be used 
for completely unknown exportations to describe the document in a formal 
language other than source code. If you trust how your neighbor handles 
the data then there no reason to use a DTD or any concept of it. Raw XML 
is only meant to be one step away from binary data, where raw XML is 
portable byte order and binary data is obviously not "native" once 
transmitted.

I don't see how JSON is an improvement from that.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 03 Aug 2010 09:30:55 -0700

> Web Development, Software Engineering, Virtual Reality, Consultant

In fact, JSON's best feature is being able to do the eval(), yet those 
of us that written VMs should already know this. Verification killed 
that feature when they tried to use it in out-of-domain style.

On that note, I suggest to change the VWRAP docs where if people request 
JSON (i.e. "application/json-*" ) that they actually want RSS or ATOM 
styled structures. Instead, only offer RSS or ATOM structured JSON (i.e. 
"application/json-atom" ). If they want more raw than that, then it just 
makes sense to use XML. It's too costly for "us", and they don't realize it.

There may be other formats besides RSS or ATOM, so its not a moratorium, 
yet these two are popular solutions already well established. I'm sure 
different audiences are going to quibble, but I leave it up to you to 
decide on support steps to change and how to present them.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 03 Aug 2010 10:05:22 -0700

And one more thing...   (yes, I was "listening")

To expand on Zha's use-cases:

We should have a "application/xml-org-ietf-vwrap-" prefix for mime types.

That'll help with transitions, so I think this group already knows their 
postfixes.

Dzonatas Sol wrote:
> On that note, I suggest to change the VWRAP docs where if people 
> request JSON (i.e. "application/json-*" ) that they actually want RSS 
> or ATOM styled structures. Instead, only offer RSS or ATOM structured 
> JSON (i.e. "application/json-atom" ). If they want more raw than that, 
> then it just makes sense to use XML. It's too costly for "us", and 
> they don't realize it.
>
> There may be other formats besides RSS or ATOM, so its not a 
> moratorium, yet these two are popular solutions already well 
> established. I'm sure different audiences are going to quibble, but I 
> leave it up to you to decide on support steps to change and how to 
> present them.
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 Aug 2010 06:14:46 -0700

I went a step further to bring back a decade old idea off the shelf... 
to actually implement some of these RFCs in the system other than user 
land. (Patents expiring... "Win7" probably last major "WNT" edition... 
XP support extended... DirectX11 is vapor except "Render-Morphium" code 
... X11 looks ready for next leap.)

I'm going to suggest that IETF VWRAP makes a good foundation to bring 
XML to the "kernel" level. Those of us that have worked on that idea 
know that Linux kernel is also kernel modules and subsystems, and that 
there hasn't really been a reason to implement RING1, so its only been 
RING0 and RING3. I think those still mean something.

This suggestion would simplify shared media, its synchronization, and 
atomicity. Don't expect it to be framebuffer speed, because that's 
unidirectional. We can assume shared media is bidirectional, so the 
concepts of the synchronization are very similar to VWRAP.

The critical issue to resolve is that it doesn't need to support general 
mime types already specified. It could just filter everything out, and 
we could just start with the mime type noted below. I would like VMS...  
mainframe environment be aware of this kind of UNIX step and decide if 
they need a diagnostic mode (RING2/RING0), which they would need to 
suggest. The shared media may be "reactive". If I hear nothing about it 
from this, then I'll assume either it wasn't heard or there is no 
concern, which justifies our time. (I'm not gonna answer leading 
questions about this.)

For backword compatibility, the .NET/Mono wrap around ".exes" make a 
good model to embed such XML. Then the obvious follow-up is to make an 
IL.XML more formal, but that is something this group doesn't need to 
maintain (which was a made obvious business concern.)

Thanks for reading,
Dzonatas

P.S. I was recently reminded Bell Labs still holds interest in a certain 
nuclear license. Mesh networks is inevitable. Don't blame me for talking 
about it.

Dzonatas Sol wrote:
> That'll help with transitions, so I think this group already knows 
> their postfixes.
>
>
> Dzonatas Sol wrote:
>> Dzonatas Sol wrote:
>>>
>> In fact, JSON's best feature is being able to do the eval(), yet 
>> those of us that written VMs should already know this. Verification 
>> killed that feature when they tried to use it in out-of-domain style.
>>
>> JSON (i.e. "application/json-atom" ). If they want more raw than 
>> that, then it just makes sense to use XML. It's too costly for "us", 
>> and they don't realize it.
>>

--

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Wed, 4 Aug 2010 13:34:15 +0000

Ummm.. Huh?

I'm having serious problems parsing this.  I *think* you mashing together the concept of mime types and plugins with some protection domains and sandboxing (which you refer to in terms of processor protection rings). Unless you really are advocating pushing stuff into the kernel..

Anyway, this is all implementation details.  How does it relate to the protocol specs?

Sorry if this came of grumpy. I don't mean it that way. I seriously don't understand the point your trying to make.  And I have a fair bit of experience with all the related topics.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dzonatas Sol
Sent: Wednesday, August 04, 2010 9:15 AM
To: Dzonatas Sol; [email-masked]
Subject: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375

Thanks for reading,
Dzonatas

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 Aug 2010 17:59:59 -0700

Dickson, Mike (ISS Software) wrote:
> How does it relate to the protocol specs?
>   

The protocol needs to be aware of springboard functions, which are only 
used for organizational needs. As functions are implemented in the 
subsystem and accessible from user land, there has always been an 
increased chance they'll be used as a standard. A review of the 
use-cases, we can select a few for AOT mode, and which ones fallback to 
user land. This then relates the a newer concept of the shell.

I'm familiar with the usual outcomes that have tried that and then tried 
to undo it. Those of us that have done it and have kept it stable over 
the years or have no need to change it know where we started. Our 
methods aren't probably different, so there is again another increased 
chance to rebuild each other.

There is no way to simplify synchronization and atomicity in the 
protocol itself, yet we can, for example, start with a ReSTful way to 
handle mime-types as resources and stress that the media matches a 
certain format, XML. From here, the protocol can present itself in 
timeslices, banked-memory schemes, or micro-kernels. There is also the 
lockless cache method, yet this method is best for the kernel developers 
to decide if the subsystem is allowed such technique. I've tested a 
combination of these schemes already. I cannot release specifics, yet 
the code is open source. They each add to performance, so there is no 
best method. I'm not gonna taint the protocol, yet the trust level still 
amazes me. I would call the work a peacemaker.

I'll admit, I showed some professors and it blew their mind when I told 
them a full stateful system transfer occurred in less than 100 cycles -- 
but I unloaded immediately after the proof because I knew they couldn't 
explain what just happened. Earned Highest Honors. I didn't do the hard 
work, I just added the cache and buffered the events to keep the system 
responsive. Time skew became more common, and it provided a way to work 
on it. I optimized it further on context, yet I never published that code.

I always kept in mind... should we...with no concept of context... as a 
subsystem? I just create the pen...

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 Aug 2010 18:52:22 -0700

Dzonatas Sol wrote:
>
> I always kept in mind... should we...with no concept of context... as 
> a subsystem? I just create the pen...
>

I almost forgot to mention purpose.

Have you noticed on the latest multi-core systems that they have 3D 
intraconnects? I'm thinking... well the first option is that subsystem 
mode would be the core underneath... which could do the same to the next 
one underneath.  So an array of 12x12x12 cores could do 2D meshed 
distribution with with nested execution in parallel. I did mention AOT, 
so "upwards" would be an exercise for you.

Based on QM, I would consider the bottomost core as a crystal-state. 
"Crystalized" is the atomic saved state I wrote into a VM. That's my own 
direction...

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 Aug 2010 19:34:26 -0700

Dzonatas Sol wrote:
> "Crystalized" is the atomic saved state I wrote into a VM. That's my 
> own direction...
>

Another thing before I forget... people want to "spin" the cube to think 
that would make it do certain calculations faster, yet the problem with 
that is those calculations are based on O((n_dimensions)*XYZ) style. I 
reiterate from time to time that it would be faster to just use 
something similar to pi r square, then it doesn't matter how many 
dimensions.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 05 Aug 2010 05:07:54 -0700

I read some news today, and wondered how I can talk about something. One 
thing lead to another and...

I think the terminology "hyperintraconnects" is practical to use in the 
protocol, which we've had proof for in Proton Exchange Membranes for 
awhile. I think these patents are not going to expire, yet that doesn't 
mean we don't like to share. The stock market can't even keep up with 
the actual that the value is consistently lower than whats used. Any 
economist can take one look at two different market caps and know the truth.

There used to be a concept for bubble memory, yet I think they meant the 
effect of sublimation effects in the motions of the matter in comparison 
to paravirtualization in multi-core events. It's easier to understand 
that way...

..it could be written in kids books.

Dzonatas Sol wrote:
> Another thing before I forget... people want to "spin" the cube to 
> think that would make it do certain calculations faster, yet the 
> problem with that is those calculations are based on 
> O((n_dimensions)*XYZ) style. I reiterate from time to time that it 
> would be faster to just use something similar to pi r square, then it 
> doesn't matter how many dimensions.
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 05 Aug 2010 06:24:53 -0700

> ..it could be written in kids books.

If you wondering what I am doing here in this mail-list besides 
Icesphere and VWRAP, then there is overall issue about spam.

After I reviewed all the different scheme to secure hosts and different 
HELO styles, I thought... the answer is right here. Just filter out the 
general mime types, and there is no need to encapsulate or move to 
something else besides RFC822.  Most likely then the headers could be 
minimized and the specific ones moves to there own mime-type, and you 
probably get the general idea.

On that note, I also suggested in AWG yesterday a V + USB device. Maybe 
a mime-type like  "application/xml-org-ietf-vwrap-v+usb"  just to show 
it is  enabled compared to a V - USB that is similar to a DTD version.

Hyperintraconnect that and we've sublimed a step.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 05 Aug 2010 13:54:26 -0700

> Hyperintraconnect that and we've sublimed a step.

Decade ago the I presented the idea to make .NET a domain supported by 
whatever means it can. Anotherwords, there is no TLD for .NET, yet bind 
has always worked the same. I actually never took the time to do an 
upstream lock to prove the complete model, yet others filled in the gaps.

The .NET model also contains forward-looking permission system for for 
protocol.

These domains are atomic ready. They can be part of the subsystem in the 
12x12x12 multi-core...  or .NET core.

Study corporate PEM manufacturers for contacts about the software and 
hardware for battery systems. I don't think they'll publish a complete 
model until there is "no-engine" and only what they can distribute it by 
battery systems and drive system. It's been long-term.

Salutations.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 05 Aug 2010 18:01:46 -0700

> Salutations.

Something was asked of me by PC... gotta put a face on it.

P.S. I hope his daughter makes President. =)

--

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 Aug 2010 09:05:04 -0700

Dzonatas Sol wrote:
>
> Something was asked of me by PC...
>

"Today Congress took an important step [up] ensuring that teachers stay 
in the classroom and cash-strapped states get the relief they need."

-- Barack Obama [Fixt.]

https://twitter.com/BarackObama/status/20335558327

'We are going to rebuild this economy [easier] than before, and at the 
heart of it are going to be three powerful words: "Made in America."'

-- Barack Obama [Fixt.]

https://twitter.com/BarackObama/status/20337776197

"To the naysayers in Washington who said walk away from the [engine] 
industry, my message to them is this: Don’t bet against the American 
worker."

-- Barack Obama [Corrected.]

https://twitter.com/BarackObama/status/20407571308

--

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 09 Aug 2010 11:19:15 -0700

> P.S. I hope his daughter makes President. =)

One thing people on this list didn't understand about the purpose or 
reason of my posts is... "for the kids."

For some reason they wanted to professionalize it without kids in mind, 
which is actually unprofessional.

Yesterday, I know of someone's birthday... that's been missing from my 
life. I think about "THIS" all the time...

---- mime:posted-to-opensource-dev ----

Your request to the opensource-dev mailing list

    Posting of your message titled "Re: [opensource-dev] Fixing the
Assets"

has been rejected by the list moderator.  The moderator gave the
following reason for rejecting your request:

"Your message is not relevant to the topic of this list, and has been
rejected."

Any questions or comments should be directed to the list administrator
at:

    [email-masked]

---- mime:posted-to-opensource-as-part-of-thread ----

Indeed.

That's why the legal courtsystems have to completely reveal themselves 
as religions.... now!

More specifically... the "judges"...

"... duh!"

P.S. "Impersonators?" *ahem*   Next...

---- mime:posted-to-opensource-as-part-of-thread-in-reply-to ----

Fractured Crystal wrote:
Drugs are bad.

--