On Fri, Jun 11, 2010 at 3:21 PM, Daniel Rice (דניאל רייס) <[email protected]>wrote:
> These are the possibilities I see to serailize a long value 'x': > > 1) Keep the current wire format double[2] > 3) Serialize as int[3] (bitwise: x[63:44], x[43:22], x[21:0]) > 3) Serialize as toString(x, 10) > 4) Serialize as toString(x, 16) > > #1 is the status quo, which requires a lot of parsing but at least it is > all JS native parsing. Then there is a pretty expensve operation to convert > the parts to long and add them together. > #2 requires some native parsing, but no conversion. However, it doesn't > improve on the current situation of tying the wire format to the internals > of the implementation. > #3 is elegant but requires really expensive calls to Long.toString and > Long.parseLong on both server and client. > #4 seems like a good compromise, since the long can be split up bitwise > pretty cheaply and parsed in chunks using much more efficient algorithms (no > long div/mul required). > > I can give #4 a whirl. The only issue I have is whether this requires an > RPC version bump, and if it needs to maintain backwards compatibility. > I like #4 for the long-term solution (maybe with a base64 format that gets 6 bits per char rather than 4), and I am fine with adding back the existing method as a short-term solution. It might be possible to detect which serialization method is used, but probably safest is to bump the RPC version number. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
