Hi, On Wed, Mar 18, 2009 at 2:16 PM, Santiago Gala <santiago.g...@gmail.com> wrote: > El mié, 18-03-2009 a las 11:40 +0100, Jukka Zitting escribió: >> Sounds like RMI is probably not the best comparison point. How does >> Jaffre differ from XML-RPC? Are there potential synergies with >> projects like http://ws.apache.org/xmlrpc/? > > Huh? I quote from a previous email in the thread: > >> > However, Jaffre neither does use any Web technology like HTTP* or >> > XML, nor is it interoperable with non-Java technologies.
There's more to an RPC library than the network protocol and the serialization format. After all, the essential purpose of an RPC library is to hide those details as effectively as possible. > In my book, not using HTTP and XML and not being interoperable with > other languages/platforms makes it for something to be compared with RMI > rather than xmlrpc. I'm looking at it more from a functional than an interoperability/implementation perspective. There's a difference between calling remote methods and remote procedures, as with method invocation you typically have things like remote object references, distributed garbage collection, etc. As far as I can tell Jaffre doesn't do any of that, so it's functionally much closer to procedural RPC mechanisms like XML-RPC. I'm by no means against this project, I'm just trying to better understand it's main differentiators. Will Jaffre be faster or smaller than the alternatives? Will it have better support for native Java types? Will it be more extensible or customizable? Something else? Alexander's earlier messages already suggested answers to these questions, but how will these benefits be achieved? Can some of these benefits be applied to other related Apache projects, or can Jaffre leverage the work that has already been done? BR, Jukka Zitting --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
