Re: [GNUnet-developers] GSoC

[Martin Schanzenbach]

Hi,

On Fri, 2016-02-26 at 13:04 +0200, Daniel Golle wrote:
> Hi,
> 
> I wanted to share my thoughts on two of the proposed GSoC topics for
> a
> while, now finally I remebered it in the right moment ;)
> 
> On Tue, Feb 16, 2016 at 10:53:56AM +0100, Martin Schanzenbach wrote:
> > 
> > On Tue, 2016-02-16 at 09:50 +0100, carlo von lynX wrote:
> > > 
> > > On 02/15/2016 12:11 PM, Martin Schanzenbach wrote:
> > > > 
> > > > RESTful GNUnet
> > > [...]
> > I already started a REST plugin framework and a handful of APIs for
> > my
> > own use. If you have requirements for a specific set of APIs from
> > GNUnet then it would be good if you could file a bug report so we
> > can
> > keep track of what is needed first. Moving the _whole_ GNUnet API
> > to
> > REST with a well designed HTTP-style API and good documentation
> > should
> > be the goal of this GSoC. The task is not very
> > sophisticated/innovative
> > but a nice exercise in SE and API design and it's a great way to
> > get to
> > know what GNUnet does, and how, I think.
> 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
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.
Maybe I am missing the point?
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.

- Martin

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > [...]
> > 
> > > 
> > > > 
> > > > > 
> > > > > Integration of the GNU Name System with GnuPG
> > > > > Mentors: Matthias Wachs, Christian Grothoff, Jeff Burdges
> > > Again more energy thrown at the broken client/server system.
> > > I think the way to bring e-mail users to the table is a
> > > completely different one: Emulate an IMAP/SMTP/POP server
> > > on the gnunet node and transparently repack it all to run
> > > over GNUnet/PSYC. We can even recycle code from the Bitmessage
> > > folks that already did this.
> Generally sounds great, but as PSYC is real-time only, what if the
> node on the other side is currently offline? Eg. I generally like
> to have everything turned-off while I'm sleeping, safe energy and
> bandwidth in hours where it obviously can only harm (ie. disturb
> my sleep with blinkenlights or harddrive noises). However, people
> do send emails to me while I'm sleeping and I do appreciate to
> receive them (once I'm awake). Correct me if I'm missing something,
> but
> to me it seems as this cannot be achieved with PSYC, right?
> 
> 
> Cheers
> 
> 
> Daniel