Re: [GNUnet-developers] GSoC

[Daniel Golle]

Hi Martin,

On Fri, Feb 26, 2016 at 01:06:42PM +0100, Martin Schanzenbach wrote:
> On Fri, 2016-02-26 at 13:04 +0200, Daniel Golle wrote:
> > Why are you specifying it to HTTP-based at all?
> > I believe a *re-usable* JSON-RPC, which could either be accessed via
> > HTTP but just as well using a local socket or existing message-
> > passing
> > systems like ubus, dbus, ... would be better and avoid duplicate
> > work.
> > From the OpenWrt-perspective, integration with OpenWrt's ubus would
> > be
> > great and could work with the same JSON API as for REST -- just that
> > there is no need for HTTP.
> 
> I see. The idea is to have a standardized interface with common
> conventions to allow application developers to develop an application
> and not implement a protocol client for a specific JSON-RPC definition
> (http://bikeshed.org/). If you have a JSON API implementation it just
> works and you do not have to worry about connection details. Btw I also
> disagree: message handlers like dbus are not restful. If you try to

ubus [1] does handle synchronous calls, and already uses JSON as it's
native format to communicate with applications (it uses a binary TLV
format on the wire).
This is why I thought that having the JSON API reusable for non-HTTP
applications might be a good idea, so at least the synchronous calls
won't need several translation layers (one for HTTP, one for ubus, ...)
but one for all of them could be enough.
carlo's example of jspsyc also seemed to be worth looking into.

> make them restful you will lose all the good parts like notifications.
> Tbh I would rather teach the message handler client (dbus-gnunet/ubus-
> gnunet) to speak with the GNUnet REST API than have those messaging
> systems relay JSON-RPC calls. This completely missed the point of the
> message bus. I also do not see the advantage of dbus over HTTP in this
> case. Why would you implement a JSON-RPC on top of dbus if you could
> simply use dbus messages? Sounds like overkill.

I don't get how you arrived at dbus-over-HTTP (or HTTP-over-dbus?, I
lost you, sorry). I never did anything with dbus, nor am I aware of
it's message format. I know that it does some XML stuff and that was
enough to keep me away from it. Just forget about it, it was most
likely the wrong example.

On the other hand, do you know jshn.sh? It's a small (standard) Shell
script with a couple of functions making it very easy to make Shell-
scripts understand and speak JSON.

> Maybe I am missing the point?

I guess so, because my point was simply to make sure that the JSON API
would be re-usable for transports other than HTTP.

> What I do not want is that application developers have to write yet
> another API client (for my JSON-RPC calls) that they can use over
> REST/dbus/ubus instead of directly _using_ standard message formats
> _like_ jsonapi/dbus/ubus for which implementations already exist and
> there are people who already use and understand them.

Ok, now I get you, and that was not what I intended to suggest.
Again, forget dbus and think about local scripts (connecting to a UNIX
socket instead of screen-scraping gnunet-* tools) or ubus[1] clients.


Cheers


Daniel


[1] https://wiki.openwrt.org/doc/techref/ubus