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

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

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