Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Redesign API for respondd #522
Suggestion: use JSON for the requests. Draft:
I am getting the impression we are re-inventing (read-only) HTTP over UDP here.
JSON would have the advantage of being forward-compatible: We could add further flags in the future without breaking old applications. But it is also very verbose: What you posted is four times longer than "GETZ nodeinfo". As you mentioned, "single" isn't really required, so what advantage does JSON give us right now?
(also: did you abandon the idea of partitioning the answers?)
Well, let's start by looking at the current state. There are two types of requests:
These requests are used like this:
b) is used by the old status page just with the id set to "nodeinfo". We'll need to keep this around for backward compatibility a while.
If we were to introduce a new API in 2015.2, we still must support the old APIs for a while, giving us a total of three public APIs.
Therefore, I'd like to propose not changing anything in 2015.2 but to deprecate the public part of b) now and schedule its removal for 2015.2+1. A few releases later we could replace a) the same way (or transition to NetJSON rightaway).
@tcatm, one thing I forgot in my JSON draft, but deem quite important is the "partitioned query" issue. I'd like to get this sorted out as soon as possible, as I'd like to prevent people from actually starting to use respondd via mesh-wide multicast (packet storms are never a nice thing...).
Is the "neighbour name" feature on the old status page important enough to keep supporting the old API at all?