Re: [GNUnet-developers] GSoC

[Martin Schanzenbach]

Hi Daniel,

On Fri, 2016-02-26 at 17:41 +0200, Daniel Golle wrote:
> 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.
> 
Alright there seems to me a misunderstanding here. The proposal is not
to design _a_ JSON API to expose GNUnet functionality. The proposal is
to use jsonapi (this is not an API. It's just called jsonapi) to expose
the GNUnet API. Just like you could expose the GNUnet API through
sockets or dbus or ubus or any other _format_.

Now when you want to use the GNUnet API via dbus, then you must read
this: https://dbus.freedesktop.org/doc/dbus-specification.html and the
documentation for gnunet-dbus (if it exists).
If you want to use the GNUnet API via ubus, then you must read this: ht
tps://wiki.openwrt.org/doc/techref/ubus and the documentation for
gnunet-ubus (if it exists)
And if you want to use the GNUnet API via REST/jsonapi, you must read h
ttp://jsonapi.org/format/ and the documentation for GNUnet rest (the
proposal).

The thing is that _a lot_ of developers today  use jsonapi and/or HTTP-
based protocols (see angularjs, emberjs, anything jquery) and this
number is increasing simply because HTTP is always available and _the_
transport protocol today. So I think this is an interface GNUnet needs
to attract developers of client applications.

Personally (and I know there are people that do not agree, a lot of
them) I think HTTP is a protocol that is very well suited for resource
oriented API design (e.g. REST). And jsonapi is a well-defined message
format on top of it. Hence the proposal.


> > 
> > 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.
> 
A developer (generalized) does not want to learn jshn.sh to make his
application communicate with GNUnet. He wants to/must use what is out
there and standard.

> > 
> > 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.
> 
Well UNIX scripts better use the gnunet-* tools. That's what they are
for. ubus can use the API directly, I think and expose a clean
interface itself. It does not really compare to jsonapi in any way as
elaborated above. The reason I do not propose a "Expose GNUnet API over
ubus" project is because the goal is to support widespread standards,
not niche message formats.
As you pointed out using ubus might be interesting for the openwrt
community. But comparing the ubus message format and jsonapi is
_literally_ like comparing apples an oranges... yes they are both
fruits but the contents are different, right?
Maybe you can offer a ubus project? ;)

TL;DR I want to expose the GNUnet API using a standardised, widespread
message format on top of HTTP/REST to reach a lot of devs. If you ever
read this:http://www.jsonrpc.org/specification you know why I like
jsonapi. Case in point: http://stackoverflow.com/questions/15056878/res
t-vs-json-rpc

- Martin
> 
> Cheers
> 
> 
> Daniel
> 
> 
> [1] https://wiki.openwrt.org/doc/techref/ubus