I must have missed something, or is it mostly about changing serialization of proxies? (which I didn't find in the patch)
Is the goal to enable creating a RequestFactory interface for a JSON-RPC service that's not backed by a SimpleRequestProcessor (or similar)? Given that the JSON-RPC request is still done by a RequestTransport, then it means you cannot mix JsonRpcRequest and "normal", XHR-based, requests in the same RequestFactory; so why isn't it a new interface then? (JsonRpcRequestFactory) If the goal is only to make it possible to use RequestFactory "cross-origin" (with the same RequestFactoryServlet backend as for "normal", XHR-based, RF), then what's wrong with just using a different RequestTransport? (sure, passing JSON in the URL looks ugly, but it should "just work") Well, you might have very good reasons for doing this, and I'm not trying to dispute them; I was stepping in only about the ISO 8601 date encoding issue, and thought I should share my thoughts about the overall patch at the same time. http://gwt-code-reviews.appspot.com/1355804/diff/1/4 File user/src/com/google/gwt/autobean/shared/ValueCodex.java (right): http://gwt-code-reviews.appspot.com/1355804/diff/1/4#newcode95 user/src/com/google/gwt/autobean/shared/ValueCodex.java:95: // XXX Figure out how to decode iso 8601 dates in compatible manner On 2011/02/15 19:29:05, rjrjr wrote:
Is that really possible?
return DateTimeFormat.getFormat(PredefinedFormat.ISO_8601).parseStrict(value)); ? http://gwt-code-reviews.appspot.com/1355804/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
