Re: [GNUnet-developers] GSoC

[Andrew Cann]

By the way, gnunet-dbus already exists: https://gnunet.org/svn/gnunet-dbus
I started writing it because GNUnet needs some kind of standard
RPC/notifications interface, whether it's JSON-RPC, dbus, ubus or whatever.
Implementing GNUnet's IPC socket protocols by hand is a real chore and using
the C client libraries isn't always an option.

Also, since it came up, dbus only uses xml for describing APIs. Dbus messages
use an efficient binary format.

On Fri, Feb 26, 2016 at 05:24:08PM +0100, Martin Schanzenbach wrote:
> 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
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Digital signature