Brian Slesinsky has posted comments on this change.
Change subject: Use JSON.parse() instead of eval() to deserialize rpc
callback payload
......................................................................
Patch Set 4:
(4 comments)
To add to the versioning mess, there are Google projects that are using
GWT-RPC to serialize data without using the "RPC" part (via hacks). For
example, GWT-RPC encoded data might be stored client-side or embedded into
the HTML page served up at initial page load. I think they're just calling
the static methods and not worrying about versioning since we haven't
changed the protocol in years. So this could cause unexpected breakage for
them. On the other hand if they're using a serialization policy they're
probably used to it :-)
It seems like we should do this gradually and start by supporting 7 and 8
for decoding, and make the decision in the caller to use version 8 when we
know it's safe?
We will need to announce the change for people using trunk and include it
in release notes for the next stable version.
....................................................
File
user/src/com/google/gwt/user/client/rpc/impl/AbstractSerializationStream.java
Line 44: * one in that it supports {@links RpcToken}s.
update comment
....................................................
File
user/src/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamWriter.java
Line 191: int version = isJsonParseSupported() ? getVersion() : 7;
Maybe extract a "chooseClientVersion()" method?
....................................................
File user/src/com/google/gwt/user/server/rpc/RPC.java
Line 381: AbstractSerializationStream.SERIALIZATION_STREAM_VERSION);
This is tricky. Seems like there are four choices:
(1) If we bump the version to 8 here then all clients need to immediately
support version 8 for decoding responses. (That includes IE6/7 since we
haven't dropped them quite yet.)
(2) Leave it leave it at 7, so we don't need to worry about getting version
8 to work in old browsers. But that means new browsers need to handle both
version 7 and version 8 responses.
(3) I was hoping that each permutation would only need to support one
version. To do that, responses should always use the version sent in the
request, as you've started on, but we would also need to choose the correct
version for sending failures. In that case I'd deprecate this method and
force the callers to make the decision. (But we're still faced with
choosing a version for the deprecated method.)
(4) Wait to commit this change until we've actually dropped IE6/7.
Line 455: AbstractSerializationStream.SERIALIZATION_STREAM_VERSION);
Similar version issues apply here, except that you've already fixed it for
the success case. I think we should deprecate this method. We should choose
the same version here as in encodeResponseForFailure (use the same
constant).
--
To view, visit https://gwt-review.googlesource.com/2900
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Ahlroos <j...@vaadin.com>
Gerrit-Reviewer: Brian Slesinsky <skybr...@google.com>
Gerrit-Reviewer: Colin Alworth <niloc...@gmail.com>
Gerrit-Reviewer: John Ahlroos <j...@vaadin.com>
Gerrit-Reviewer: Leeroy Jenkins <jenk...@gwtproject.org>
Gerrit-Reviewer: Matthew Dempsky <mdemp...@google.com>
Gerrit-Reviewer: Thomas Broyer <t.bro...@gmail.com>
Gerrit-HasComments: Yes
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
