freifunk's api is re: a directory of networks not nodes. The json would basically be a url we maintain about our network that provides metadata such as name of our network, number of nodes, access policy, URLs for more info, etc.
The json just represents our entry in a directory (or multiple directories) of mesh networks. I'm pretty sure no one is suggesting using json as a database, that doesn't make any sense...
Traditionally JSON is the way you'd interface with a database through
a web app and not the database itself. The real problem is that JSON
is a *data structure* and not a *database*. All the awesome tools one
might want to use for sorting data sets are written for relational
databases and not JSON objects.
Using anything but a relational database doesn't make much sense to me
if we are to prepare for the beautiful future of 100k+ node meshes.
Writing a relational database to JSON object script is trivial, I'd
put money on multiple libraries existing in all popular languages for
just this.
Not all mesh networks are created equal, for example some route on
layer 2 while others route on layer 3. Should every entry in the JSON
"database" contain both a MAC and IP address because of this? There
are thousands of other variations which would each require their own
JSON attribute even though 95% of the nodes may leave it undefined.
Instead of defining a shared database efforts should be focused on
defining a shared data structure. This data structure can be (and IMO
should be) JSON and would contain a list of common attributes, not an
all-inclusive list of attributes. Each organization can define their
own database and need only write a script to export common attributes
into the JSON shared data structure.
-- rhodey
On 09/25/2013 02:57 PM, Mitar wrote:
> Hi!
>
>> On a general note I'm highly skeptical of any database built on
>> top of JSON.
>
> What's wrong with JSON?
>
>> My hope is for an API to be built for this dataset such that
>> individual mesh networks are not forced into using this one size
>> fits all biz.
>
> That is really just a question how API is defined. From what I see,
> API is defined in a collaborative fashion through GitHub. So if
> one particular network needs something special, you can add this to
> the schema. And then everybody else benefits as well. I don't see
> how this is "one size fits all", but more "let's find/make the one
> size which fits all". And we are not so differently shaped that
> this would be impossible.
>
>
> Mitar
>
_______________________________________________
mesh mailing list
mesh@lists.sudoroom.org
http://lists.sudoroom.org/listinfo/mesh