1:26 p.m.
This might turn out to be really valuable.
Your analysis is pretty much to the point:
Overlay types are difficult on a detyped API.
At least it would mean that we need to create overlay types, per use case
(i.e read operation). So in the end the base64 approach might turn out to be a real
productivity boost.
Regarding the performance characteristics:
That doesn't worry me too much. You get slow and unresponsive GWT apps
for different reasons (too much requests, no caching, fine grained model representations,
etc).
I will definitely give it a try.
Btw, how does the client client serialize the data? Is it implemented as well?
Ike
On Feb 10, 2011, at 5:12 PM, Jason T. Greene wrote:
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