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. Dan On Fri, Jun 11, 2010 at 3:11 PM, John Tamplin <[email protected]> wrote: > On Fri, Jun 11, 2010 at 3:07 PM, Daniel Rice (דניאל רייס) <[email protected] > > wrote: > >> Right now, the standard RPC format hasn't changed (although deRPC has, >> since the whole point if to be able to eval the payload into the client). >> So anyone who has a custom RPC system needs a way to generate a double[2] >> from a long. > > > Ok. > > >> Longer term, I'd like to transmit longs as an int[3] instead, in which >> case I would agree that it would be good to insulate subclassers from the >> details of the wire format. >> > > Since it is actually going to be transmitted as ASCII characters anyway, I > am not sure it is better than just sending the string representation of the > long and processing it normally rather than parsing multiple values. > Especially currently where the work to parse two doubles and convert them > to 3 ints seems far more than just doing the straight parse anyway, and it > also makes the server-side much simpler. > > -- > John A. Tamplin > Software Engineer (GWT), Google > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
