Am Dienstag, den 09.12.2014, 18:24 +0100 schrieb Jan Lühr:
> Hallo,
>
> ich hab' nochmal nachgedacht:
> - Jedes Objekt sollte ein type-Version Attribut haben. Bspw. eignet sich
> das Format auch dazu, Daten im Mesh via Alfred zu verteilen. Wenn dort
> jetzt Nodes mit vers. Firmware laufen, die vers. Versionen ihrer
> Node-Attribute durch die Gegend senden, hilft es zu wissen, welche
> Version das Schema hat
> - Ein Node sollte - unabh. von der Statistik, weitere nicht
> standardisierte Attribute haben dürfen, die in Form einer Tabelle
> gerendert werden.
> Z.B. {'type': 'info', 'name': 'model', 'value': 'TP-Link TL-1043ND}
> - Hinter jedem Objekt sollte eine last_update String sein um alte Daten
> zu erkennen.
> - Zu jedem Objekt sollte es ein Freitext-Feld
> {'comment': 'Ein Text'} geben. Die Infos werden dann als Hinweistext
> rendered.
>
> Gibt's sonst noch Ideen?ich würde nicht pro Attribut eine Version vergeben, sondern nur für eine Gesamtspezifikation. Sonst kommt man doch gar nicht mehr hinterher... type ist als Attributname auch nicht so dolle, weil es im JSON-Schema für den Datentyp steht. Du kennst das doch, oder? http://json-schema.org/ Ansonsten würde ich erstmal mit einem minimalen Set an Informationen beginnen und nicht versuchen, jetzt schon alles reinzuspezifizieren. Und da finde ich den Ansatz von Tino ganz gut. @Tino: Die Objekte wie User sind aber optional, oder? Im nächsten Schritt würde ich das in eine JSON-Schema-Definition überführen. Ab dann sollte an dieser Definition weitergearbeitet werden. So läuft das auch bei der Freifunk-API... Liebe Grüße Andi
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ WLANtalk mailing list [email protected] Abonnement abbestellen? -> http://lists.freifunk.net/mailman/listinfo/wlantalk-freifunk.net Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
