Hi, On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen <mikkel.kamst...@gmail.com> wrote: > 2009/3/2 Havoc Pennington <havoc.penning...@gmail.com> >> >> Anyway, I think there is no difference between method calls and >> message passing. The only difference is in whether the client side API >> is made to look just like a native object. But that's totally >> orthogonal to the IDL and to the wire protocol. > > To quote yourself: "This is perhaps a misunderstanding". Or at least a > provocative statement :-) > > For instance Steve Vinoski (one of the RPC/distributed systems grand old > men) has a lot of blog posts devoted to the subject of RPC vs message > passing. A good starting point is PDF paper linked here: > http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/ > > I think you can put an RPC style API on top of an IDL based on message > passing, but putting a message passing API on top of an RPC style IDL might > not be a good idea (depending on the IDL in question of course as well as > the nature of the actual remote transport mechanism). >
I agree with what Vinoski says there, but he's pretty much talking about the API, not what's on the wire. There's only so much you can put on the wire; i.e. some kind of messages ... given that it's a TCP socket, all you can change really is what format they're in. I can send a dbus message and get back a dbus reply message, or send an http request and get back http reply. I'm sending some parameters to the remote, it does something, it sends back any results. Anyway dbus has messages on the wire but I think that's quite happy to be mapped to an rpc-looking (method call) sort of API, or not, as people see fit. Personally my favorite mapping is in JavaScript and looks like a method call except the method takes a callback arg which receives the return values, rather than ever returning anything immediately. Just as people might often do http. No doubt this is just terminology confusion. The point is, you can make dbus look like rpc or not. There's nothing in the protocol to stop you going either way. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list