I was hoping for homogeneity, but I think in the end I'll go with Burlap. http://www.caucho.com/resin-3.0/protocols/burlap.xtp
But if anyone figures out a way to use GWT RPC server-side, let me know! Thanks, Josh On Apr 23, 10:14 am, Vitali Lovich <vlov...@gmail.com> wrote: > Well, presumably you've properly versioned you're code so you're properly > serializing/deserializing. This is a fundamental problem with deserializing > with a different version of code than it was serialized with. It also > exists with passing things using JSON or any serialization scheme. I think > using JVM serialization results in less code, is more flexible, & is faster > than any other scheme. > > Don't have much experience with protocol buffers, > buthttp://ahlawat.net/wordpress/?p=185suggests that their slightly slower > although more efficient in terms of bandwidth. If you're not using > different languages, it'll result in having to maintain the message format > explicitly as opposed to implicitly in your java code. > > On Thu, Apr 23, 2009 at 10:03 AM, jhulford <jhulf...@gmail.com> wrote: > > > Depending on how you're updating your code across your multiple > > servers, JVM serialization can be a pain to try and deal with, > > especially for code bases that are constantly being updated. > > > I don't believe that you'll get far trying to use the GWT RPC stuff in > > straight java. If JSON isn't for you, you can also look into something > > like protocol buffers as the data interchange format. > > > On Apr 23, 9:35 am, Vitali Lovich <vlov...@gmail.com> wrote: > > > Well, I'd imaginge there'd be a serious problem using the GWT > > implementation > > > - doesn't it use JSNI at points? You could try to write one inspired by > > it > > > using guice. > > > > The JSON transport is pointeless going between two java servers - just > > use > > > regular serialization. You'll see much faster performance & you don't > > need > > > to write any code for that (the JVM takes care of it for you). Also, the > > > JVM serialization approach is far more robust & reliable & has less > > > restrictions. > > > > For the asynchronous part, you could launch a new thread that establishes > > a > > > TCP connection & calls back your callback when it's done. > > > > Optionally, you could use UDP datagrams whereby the callback will happen > > on > > > the event loop. > > > > You still have to of course write thread-safe code either way. > > > > On Thu, Apr 23, 2009 at 4:23 AM, Salvador Diaz <diaz.salva...@gmail.com > > >wrote: > > > > > Well, server-side code, the RPC implementations, are just normal java > > > > servlets so you should be able to do anything your servlet container > > > > allows you to do. > > > > > > (I can't > > > > > test this code right now because the Google App Engine plugin on the > > > > > Mac doesn't seem to run hosted mode correctly). > > > > > On the other hand, the google app engine only allows to use a subset > > > > of java 6 so it's possible that your code example won't work without > > > > modifications. You can use GWT and GEP without the app engine though > > > > so you CAN test the code (just remove the app engine sdk from your > > > > project). > > > > > Cheers, > > > > > Salvador > > > > > On Apr 23, 3:59 am, JavaJosh <javaj...@gmail.com> wrote: > > > > > Hello, > > > > > > I actually rather like the GWT RPC API and was hoping to use it for > > > > > more than client/server communication - in fact, I want to use it for > > > > > server/server communication. Here is some example servlet code: > > > > > > http://gist.github.com/100232 > > > > > > The callService() method would be designed to hit a different server, > > > > > of course. > > > > > > BTW the attributes of GWT RPC that I like is the JSON transport, and > > > > > the asynchronous API. I also like the idea of dealing with > > > > > communications in a more homogeneous way. --~--~---------~--~----~------------~-------~--~----~ 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-Toolkit@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 -~----------~----~----~----~------~----~------~--~---
