Just did some digging in, and I *think* it is possible with some restrictions. The restrictions being -
- No support for request headers - Reduced error handling. For example, a 404 cannot be detected easily... The basic idea is to use DeRPC infrastructure because it already returns JSON.. and try to override the RequestBuilder class so that the communication channel is a <script> tag instead of a XHR. *Client Side changes* 1. Inject a custom RpcRequestBuilder via RemoteServiceProxy.setRequestBuilder(). Lets call it JSONPRpcRequestBuilder 2. In JSONPRpcRequestBuilder.doCreate(..) method, return a custom RequestBuilder. Lets call it JSONPRequestBuilder. 3. JSONPRequestBuilder class does all the heavy lifting. Override *all*public methods. The serialized RPC data is available to this class, so you just need to URL encode it and construct a url 4. Then just use built in JSONP classes to actually make the request 5. You'd have to write an adaptor between RequestCallback (from RequestBuilder) and AsyncCallback<T> (from JsonpRequestBuilder). 6. Not sure how you'd typecast to the correct response object though. Perhaps you may have to leverage the deRpc infrastructure - since it already consumes JSON objects in its response. *Server side changes* This should be straighforward. The payload is present in a url parameter. Use RPC class to decode the request, invoke the method and get the data. Again, it would make sense to use deRpc as the starting point - since you need to return JSON. There may be unforeseen problems, but I think it is possible to get it working. And I guess there are advantages to it as well, you can truly share you GWT services and no longer worry about cross domain issues. --Sri On 17 June 2010 01:21, Chris Lercher <cl_for_mail...@gmx.net> wrote: > Hi Sri, > > I mean of course, that there would have to be a component (e.g. > Servlet) on the server side, that re-translates the get request, and > then calls the RemoteServlet (or something underlying), as if a usual > GWT-RPC request had been issued. Se we would basically use JSONP as a > tunnel. > > [The defense against CSRF would have to be done using a separate > technique, but let's forget about that for a moment.] > > Chris > > On Jun 16, 9:42 pm, Sripathi Krishnan <sripathi.krish...@gmail.com> > wrote: > > No, it won't. > > > > 1. GWT RPC exclusively uses POST. JSONP uses a <script> tag, which is > > essentially a GET request. You can't make a POST request using a > script tag. > > 2. RPC adds custom http headers to the request (X-GWT-Permutation, or > > something like that). You cannot setup custom http headers using a > script > > tag, or anyother html tag. > > > > Because of these two, RPC cannot be wrapped in a JSONP call. > > > > The restrictions on the URL length are not that prohibitive. GWT > supported > > browsers allow atleast 2KB, with the newer ones allowing more. That > usually > > is sufficient for most RPC calls. > > > > --Sri > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
