On Tue, 2012-01-03 at 16:38 -0800, Christian Hergert wrote: > Hi, > > On Tue, 2011-12-27 at 06:52 +0200, Dov Grobgeld wrote: > > I created jsonrpc client/server (http://json-rpc.org/) library through > > glib/gio for remote controlling my application. It is available at: > > > > https://github.com/dov/glib-jsonrpc > > > > Comments and contributions are welcome. > > Just got back from holiday and thought I'd post a few comments. > > First off, I think this sort of thing is useful. Especially when you > consider the possibilities of automatically discovering applications > running near you using avahi. (A remote control application becomes > trivial). > > I'm not a fan of the approach to hand-writing the HTTP responses. There > are so many quirks in HTTP clients. SoupSessionAsync suits the job well > and scales more than well enough for this use-case. I imagine it would > also make it easier to handle multiple async commands concurrently. The JSON-RPC doesn't define a transport agent because it can be transported over any protocol it fits in. It shouldn't be tied to HTTP when for example xbmc (which is the reason I wrote my library) provides JSON-RPC over standard TCP. GIOStream is a good choice for transport but it does need some help in HTTP department.
> As for the API, I'm not a huge fan of registering commands with a > generic callback scheme. It requires lots of boilerplate code which we > used to deal with in the early DBUS days (well, if you support > parameters, not sure this does yet). I would like to see a design where > you register a GObject at a path, like GDBUS, and GObject Introspection > is used to route the given method. Parameters would be passed in as the > POST body with a Content-Type of application/json. Then, a single, > generic marshaller could be written to convert the argument parameters. I actually wanted to do this with my library but the problem is that you probably don't want to take an exclusive approach to it. I imagine that there's at least a few JSON-RPC implementations out there that uses weird notation like "notify_func[something]" and another using "do_stuff::abc" whereby they can mean a whole host of implementation specific things. That's why initially I just have an interface with a single function `find' that takes a name and returns a delegate. Regardless of what you plug on top of this, that particular interface is necessary in order to allow *any* kind of implementation to work. > Additionally, this would allow for discovery of a given methods > parameters with a GET request to the given method by describing them in > a JSON response. Or a list of methods available with a GET to the > objects path. Of course introspection is desired but as the spec doesn't define any introspection methods, this should be an elective per instance. > And at this point, I expect flames about re-implementing DBUS. However, > I still find it useful in cases where DBUS clients aren't viable (JSON > API server, application controllable by iOS/Android, etc). No flames, just reminding you that there is a specification and we should adhere to it 100%, or in some cases maybe even be liberal (see my json_rpc_bridge_{request,notify}_verbatim, which I put in both for performance and non-conforming 3rd party reasons) _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list