Why not change deRPC? On Thu, Jun 17, 2010 at 9:11 AM, Daniel Rice (דניאל רייס) <r...@google.com>wrote:
> We thought about this, but the conclusion was that it would be better not > to expose yet another internal format. We do use this format for the deRPC > implementation. > > Dan > > > On Thu, Jun 17, 2010 at 12:08 PM, <cromwell...@gmail.com> wrote: > >> >> If they're being eval'ed, why not transmit the long as a JSON triple, >> like [li,mid,hi], and make a long out of it, it should be faster than >> base64 parsing, at the cost of slight bloat in the serialized stream, >> but either way, it seems a win. If longs are rare occurrences, the bloat >> not be significant, and if the # of longs were large (say, a long[] >> array), then parsing performance might be a problem. >> >> >> On 2010/06/16 20:53:36, jat wrote: >> >>> LGTM >>> >> >> http://gwt-code-reviews.appspot.com/626801/diff/1/2 >>> File dev/core/super/com/google/gwt/lang/LongLib.java (right): >>> >> >> http://gwt-code-reviews.appspot.com/626801/diff/1/2#newcode58 >>> dev/core/super/com/google/gwt/lang/LongLib.java:58: sb.append('\''); >>> On 2010/06/16 20:13:28, Dan Rice wrote: >>> > Fields in the RPC stream are JS literals that get eval'ed by >>> > ClientSerializationStreamReader.eval. The quotes make it a string >>> >> literal. I >> >>> > can move the quoting login into the RPC code, the cost being >>> >> spinning up an >> >>> > additional StringBuilder. >>> >> >> Ok, from FTF discussion we figured out they aren't needed on C->S >>> >> messages >> >>> because the server is just doing a split, but S->C is processed by an >>> >> eval. >> >> >> >> http://gwt-code-reviews.appspot.com/626801/show >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
