If you want to continue hosting your server-side logic and there's a significant investment into GWT RPC there, isolate your client-side JS that you produce when you compile just the classes surrounding client-side RPC. Look into the way GWT exposes itself through "native" JS calls. You may want to write some convenience factories or static API around your RPC API. And the continue hosting this smaller client JS profile along with your server and tell your partners to dynamically link with it, same as they would link to jquery JS off the jquery web site. That way their JS will talk to your JS and your JS will be of the same origin as your server code and will be able to talk GWT RPC without any issues.
On Wednesday, December 5, 2012 4:12:53 PM UTC-5, Andrei Volgin wrote: > > The right approach is to expose an API that your partners can use to build > their own apps to communicate with your server/data layer. You can also > open-source your client, or create a client library for building a client > app. If you open your client, it will have to talk to your servers using > the same API that you expose to your partners. If you open the client-side > library, your own client may remain closed and use RPC, while the open > client library will use the API. > > Andrei Volgin > > > On Tuesday, December 4, 2012 6:09:43 PM UTC-5, Ben wrote: >> >> Thus the idea to split our application into two App Engine applications >> .. one in control of the partnering company and one in our control .. Of >> course the problem is that those 2 need to communicate .. >> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/YDtIcwCxXxQJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
