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 _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
