Re: Announce: glib-jsonrpc

[Joakim Sindholt <opensource zhasha com>]

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)