Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375

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: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf Of Dzonatas Sol
Sent: Wednesday, August 04, 2010 9:15 AM
To: Dzonatas Sol; vwrap@ietf.org
Subject: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375

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:
> 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:
>> Dzonatas Sol wrote:
>>>
>>> I don't see how JSON is an improvement from that.
>>>
>>> --- https://twitter.com/Dzonatas_Sol ---
>>> 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.
>>
>
>

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

_______________________________________________
vwrap mailing list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap