[jboss-as7-dev] DMR GWT Prototype
Jason T. Greene
jason.greene at redhat.com
Thu Feb 10 11:12:28 EST 2011
There shouldn't be any. XHR has no problem with anything that is legal
utf-8. The only JSNI used in this approach is for ieee754
encoding/decoding which is a portable implementation. Any kind of
portability problem would have to come from a GWT conversion bug.
However, we could easily work around any of them.
On 2/10/11 2:42 AM, Heiko Braun wrote:
>
>
> Can you think of any browser incompatibilities with the Base64 approach?
>
> Ike
>
> On Feb 10, 2011, at 7:08 AM, Jason T. Greene wrote:
>
>> I was able to port DMR so that it can be used with GWT to send and
>> receive DMR's native externalized binary format via client-side javascript.
>>
>> https://github.com/n1hility/jboss-as/tree/detyped2
>>
>> A pure binary protocol is not possible in all browsers, so the
>> implementation has to base64 encode the stream.
>>
>> The main advantage to this approach is that there is essentially no loss
>> of information (all type info is preserved), and the API works very well
>> at dynamic access and is exactly the same as the management API used in
>> server code. In addition parsing requests on the server is much more
>> efficient since there is less transformation and pattern matching.
>> Lastly it has the potential to be much more space efficient.
>>
>> However, due to Javascript's very poor binary handling, lack of
>> streaming, and lack of native floating point encoding, client side
>> execution is on average 2x+ slower than directly evaling JSON code. That
>> said, processing a dump of the entire model took on average 9ms (in
>> webkit based browsers), and in the worst case (firefox) took 20ms. So
>> the times are still somewhat reasonable.
>>
>> In addition to being faster on the client side, eval'd JSON does not
>> require maintaining the DMR API. On the other hand JSON usage in GWT is
>> clumsy if you aren't using overlay types, and overlay types are not
>> helpful to dynamic client code (dynamic as in being able to discover and
>> manage resources based on resource descriptions as opposed to static code).
>>
>> Lastly, JSON output, by its nature, loses type information. Although
>> this could be worked around if it's a problem by adding type identifiers
>> to all node values, at the cost of looking less JSON like (extra verbose).
>>
>> So ultimately it's up to everyone working on the console as to which
>> direction this goes. I can easily support both mechanisms on the server.
>>
>> --
>> Jason T. Greene
>> JBoss, a division of Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
--
Jason T. Greene
JBoss, a division of Red Hat
More information about the jboss-as7-dev
mailing list