Re: Basic ietf process question ...

Martin Thomson wrote:
> On 4 August 2012 08:52, Mark Nottingham <mnot(_at_)mnot(_dot_)net> wrote:
> > > The other interesting case is where large amounts of data arrive in a stream.
> > > SAX and SAX-like libraries makes this easy to implement with XML. I hope
> > > there's an equivalent for Json; if not there needs to be.
> > Funny you mention that, I was just looking into that yesterday.
> >
> > This seems to be in the front running:
> >   http://lloyd.github.com/yajl/
> The conclusion that I reached on this subject was that both XML and
> JSON are poorly suited to streaming use cases for large datasets.  Try
> implementing XMPP "framing" some time and tell me afterwards how much
> you love SAX.
>
> I prefer CSV or lots of small objects.
+1, too much overhead, cries/needs for compiling and p-coding it comes 
in.  But it depends much on how much dynamic vs static data is 
involved in the application.  For on the fly dynamic processing, too 
much overhead and relaxing on strong syntaxing (i.e. allow for 
errors). Of course, thats getting cheaper these day.  One other issue, 
at least for us, to make it more useful, more layers will be needed. 
So this library may be great, but not for the layman to use. It will 
good for the systems level people to write the high layers tools (for 
application developers) perhaps.  That has been the dearth for many 
vendors who have to interface with different flavored APIs.  Single 
sourcing it is a strategic benefit for many which means having to 
write/port/convert the libraries into other languages.
Regarding the XML related question for IETF processing, well, the way 
I look at it is document writing should not involved requiring XML 
knowledge. Its already complex and it gets even more complex with XML 
Schemas, so its the last thing I want to spend time learning, 
relearning or refreshing on on.   But for usage as a tools to help 
IETF processors, management, perhaps, in what is essentially a static 
application it probably ok and keeps up with a direction in using XML 
for all things static (and even dynamic, not always the best result). 
It can help with I/O Communications, perhaps decentralization areas, a 
bunch of things once a common format is used.  But lets not require 
document writers having to know XML and XML schema just to be involved 
and productive with the IETF.
PS: For XML processing, we use the super light weight PUGXML C/C++ 
code in many areas
http://www.codeproject.com/Articles/3502/PugXML-A-Small-Pugnacious-XML-Parser

For JSON, well, thus far, we only needed it for web clients and 
javascript applets, and javascript is naturally JSON.  For the server 
side, I am probably going to relook at V8 again (googles stuff) which 
is also used for Chrome.
http://en.wikipedia.org/wiki/V8_(JavaScript_engine)

The nice thing I felt was the ability to built on top of it, new 
layers, language independent imports and more importantly, JIT "Just 
in time" pcode compiling/processing which is how Chrome gets its 
Javascripting speed from.
--
HLS