[jboss-as7-dev] DMR GWT Prototype

[Jason T. Greene]

On 2/10/11 1:26 PM, Heiko Braun wrote:
>
>
> 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).

Yeah I suspect what you would have to do to get a dynamic API is to 
write a similar API to whats in DMR and have it use JSNI with reflective 
analysis (e.g. javascript typeof).

> 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.

Ok, let me know if you run into any issues. There is definitely a lot of 
room for improvement in reducing the size of the binary encoding.

> Btw, how does the client client serialize the data? Is it implemented as well?

Yeah you just do node.toBase64String() and pass that to 
RequestBuilder.send().

It follows the same process. Actually it's the client send problem that 
lead to the base64 approach. On the receiving side you can do binary 
data with XHR if the server sends a content type with a charset of 
x-user-defined. This is a special unicode encoding that happens to treat 
the upper bit ranges as being private, and so does no transformation on 
them. Unfortunately this mechanism does not work reliably with 
XHR.send() on all browsers. Mozilla based browsers require a special 
sendAsBinary method, and IE (only latest versions) require special 
non-portable javascript types. They all have no problem taking valid 
utf-8, so base64 seemed like the best solution until browsers have 
better support for binary data. Mozilla 4 already has started providing 
a special byte buffer API.

-- 
Jason T. Greene
JBoss, a division of Red Hat