freifunk / api.freifunk.net Goto Github PK

add category podcasts to support podcast feeds and later aggregate them

add example like 51.12345

The sample API result from Weimar contains a specification for an empty network which conflicts with the specification requiring a network given.

Maybe other conflicts with the specification are present too.

Sollten wir die directory.json mit Ihrem Schema nicht in einem eigenem Repository (=diesem) verwalten und die Beispiel-/Anwendungen in einem oder mehreren eigenen?
Das Repository ist zwar von der Struktur noch übersichtlich, aber von der Commit-History geht das ziemlich querbeet.

distribute our directory all over the network and make it accessible via one address

goal: make our directory high available, so scripts and website can work with it, use the last valid version from github

add-on: also distribute a file created by the collector containing all aggregated json files

waiting for discussions and suggestions

The api specs are in the specs folder. The generator should use these files instead of depending on a copy of these files.

e.g. within the networks section, we should try to get a better layout for headings. can be solved by css and classes in generator form

• Nodewatcher
• ffsomething
• kml

Liste von einer bzw. mehreren API URLs und der dort jeweils verwendeten API-Formats, d.h. dass Einsprungpunkte bereitgestellt/announciert werden können, an denen in definierten APIs Informationen zu Knoten der jeweiligen Netze bereitgestellt werden.

Ziel: alle communities können die Nodedaten der anderen nutzen, um sie in ihrer Kartenlösung darzustellen bzw. es können übergreifende Karten entstehen.

insert a select box, that loads the community file into an editor with validate button

http://hackerspaces.me/ sieht chic aus, wie wäre das mit den freifunk-daten?
code liegt unter https://github.com/trevorpower/hackerspaces-status-wall

Ahoi,

eine Frage:
Das "0.1.json" vermischt statische Anteile (Name, Location, etc) mit dynamischen Anteilen (status).
Wäre es nicht gut das zu trennen?
Zum transparenten Übergang könnte ich mir vorstellen, daß das Attribut "status" zum einen wie bisher ein JSON-Objekt enthalten kann, zum anderen aber auch eine URL (JSON-string) enthalten kann, welche dann die URL enthält über die das Status-JSON-Objekt abgefragt werden kann.

Was denkt Ihr?

Ich hab' zwar nicht viel Ahnung von Python, aber wenn Ihr meinen Vorschlag für gut haltet, könnte ich mal versuchen das auch einzubauen.

Viele Grüße

at the moment there is only "OLSR","BATMAN","Babel","802.11s" possible.

please add other routingprotocols which are in use. look at Battlemesh, we also have

• batman-adv
• OLSR v2 (soon)
• bmx

eventl. Groß-/Kleinschreibung beachten?
what to do when more than one routingprotokol is in use? maybe we need another ticket

The code-formating is a big mess.
There is no consistancy between Tabs and Spaces.
This is a minor issue but should be fixed all over the repository.

The "Last Change" field is a required field in the generator. If no timestamp is given the generator should automatically add the current time in the right format.

Additionaly there could be an DateTime-Picker to enter a date maually.

"netmon"-Monitoring is used e.g. by franken and oldenburg

topic is covered by node maps

~line 53
ffApi = json.loads(urlopen(ffDir[community]).readall().decode('utf-8'))

This needs http timeout setting, e.g. 10sec

Currently Mailinglist is prefixed with mailto. I would suggest to completely leave that out and let people add it in their api-json-file or alternatively check if the mailinglist is a valid email address (contains @). If not then do not use the mailto prefix.

Many communities have their own none-icann TLD in their network, but other communities don't know what TLDs are used and what nameservers can be used for which TLD. So it would be nice, if we can collect all TLDs with nameservers in the api, that we can build automatically configfiles for DNS.

• try html5 input types with generator
• rework lastchange and event section
• check apps and collector scripts

If a valid libremap api link is given the global "libremap.net" insurance can replicate with this instance.

Please add a field for g+ site to contacts

Contact items (facebook, twitter, irc, mailing lists ...) should be restructured into a list/set of objects with following attributes:

• name (optional): human readable description
• type: type of contact (irc, facebook, mailinglist, twitter, mail, webform, wiki, ...)
• value: information to use this contact, in URI format, or user-name where no well-defined scheme exists (mailto:[email protected], but @FreifunkSampleTown)
• display (optional): short, ready-for-display version of this item.
• priority (optional): positive, non-zero integer with lower numbers denoting higher priority

the format of the value attribute should be a consciece, maschine-readable representation of the information. If display is not given it may be assumed identical to value. Depending on the type additional, pre-parsed information may be present. e.g. type=irc may contain hostname, port, channel, flags while email may contain email, contactname, subject. Such fields, if defined are optional.

A basic set of such types should be defined as part of the specification and should be understood by clients adhering to this specification.

Could README file be in English? It would be much easier for global communities to contribute and understand.

• create an array to support multiple domains, e.g. rdns
• simply call it domain

enhances #59

• move collectCommunities.py out of ffmap and create its own app
• simply combine all json files into one, update a given file
• write geoJSON as we already do, use the combined json as base
• write other formats like html tables
• look at lastchange field and set a flag if the api entry is older than ....

at the moment there is only: "ffmap", "olsr-dot","openwifimap"

Please add other Maps, so f.i.

• ffsomething -> nodemap (f.i. http://db.leipzig.freifunk.net/uptime/mapbrowser/)
• nodewatcher (f.i. https://wlan-si.net/en/map/ or https://nodes.wlan-si.net/network/map/ )
• ffhtopo (f.i. http://www.freifunk-halle.net/Map/)
• all these other maps and topos from different cities, not mentioned here.
• what about: ffsomething Google Earth KML Map? (f.i. http://db.leipzig.freifunk.net/uptime/google_earth/)

the feed merger now merges all feeds for the new freifunk.net page.

we'd like to only see blog feeds in a blog feed aggregation block on the main page, no forum discussions.

so i think we could give a choice like blog, forum, wiki, other

Felder:

• Servicename
• Beschreibung
• interne URI
• externe URI

Hallo Jungs,
wir sind mit unserem JSON File umgezogen. Ist dort bereits abholbereit.
http://ffapi.freifunk-mainz.de/ffapi_mz.json
Grüße
Wolfgang
Freifunk-Mainz e.V.

Since ebc4c09 i can not launch the generator any more, because the deps folder got removed but index.html is still depending on them.

We have a webform for a contact.

add Checkboxes for autoupdate, manual, none

I think the TODO.md should be removed and replaced with new issues.
See also #66

usage: link number of nodes in map to node map of the community

There's an existing, well-defined format available to declare an IRC channel in wide use.

cf. http://www-archive.mozilla.org/projects/rt-messaging/chatzilla/irc-urls.html

Is there any reason why the map should not be displayed in fullscreen?

use ISO code or something similar?

die Links zu den Knotenkarten sollten kategorisierbar sein:

• geographisch
• strukturell
• liste/status

Die geografische Ansicht sollte von der Karte unter freifunk.net verlinkt werden.

i think the key "störerhaftung" should be written without the german umlaut ;)

Beschreibungen der Felder verbessern, genauere Angaben zur Verwendung

...techDetails.networks.ipv4 and .ipv6 should use CIDR notation instead of IP/Prefixlen/Netmask. CIDR notation is a well defined standard to describe a subnet or prefix.

Links:
http://tools.ietf.org/html/rfc4291
http://tools.ietf.org/html/rfc4632

This is from the former "TODO.md":
"give a possibility to add new communities via web form (maybe ask the SpaceAPI developers)"

The "tag" should be named identically to the spec's version.
The spec version is "0.1", but the tag is named "v0.1.0".
The "tag" should be better named "v0.1".

Can you add a second tag?
And perhaps remove the "wrong" tag?

seems to be already done,