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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss, a division of Red Hat