[jboss-as7-dev] json vs custom parser

[Scott Stark]

Where are the binary protocol handlers located?

On 2/1/11 5:10 PM, David M. Lloyd wrote:
> On 02/01/2011 06:51 PM, Scott Stark wrote:
>> Just browsing through the as7-dev list I don't see a discussion of why
>> we have a custom parser for a json like serial format vs just using
>> json. Was this to avoid a runtime dependency, or was there another reason?
> The DMR was designed to meet the needs we have, in terms of types (JSON
> is limited in that it does not support decimal types, longs, or binary
> blobs, not to mention value types [to allow self-description], and other
> types which we use like pairs are not well-supported).
>
> The use of JSON-like model for DMR was really coincidental.  Now we
> *could* use JSON but I don't really see the need to compromise a modest
> amount of usability for a small amount of "standard-ish-ness".  For
> example one could say the model is also Perl-ish.
>
> Though my voice may not be in the majority, it is my believe that most
> of the management clients in use will either be Java, or command-line
> scripting languages like python and perl either using our command-line
> interface via shell, or via interface to JBoss Remoting (I have planned
> a Perl 5 client for JBoss Remoting, in my copious amounts of free time).
>
> The thing to note is that the JSON-like serialization format is NOT the
> primary interface for serializing DMR; the binary protocol is more
> efficient, simpler and faster to parse, and cross-platform compatible
> (more so than the equivalent JSON - even to JavaScript - because using a
> simple binary parser [and I do mean _simple_] you can support the full
> range of DMR types, not just JS primitive types).  DMR nodes implement
> Externalizable but can also be written to any OutputStream.
>
> IMO, the only reason we have a JSON parser/deparser at all is that
> _some_people_ (whom I will not name) think it's better because it's
> "standard-y" and seems easier to interface.  I have a suspicion that the
> binary protocol will supercede JSON in all use cases, including JS
> clients, due to performance and correctness reasons.  Though the burden
> is likely to fall on me to prove that. :)