Insbesondere trifft man auf JSON bei Webanwendungen und mobilen Apps in Verbindung mit JavaScript, Ajax oder WebSockets zum Übertragen von Daten zwischen dem Client und dem Server.

Serialisierung

Bei einer Abbildung von strukturierten Daten auf eine sequenzielle Darstellungsform, spricht man in der Informatik von einer Serialisierung. Die Serialisierung wird hauptsächlich für die Speicherung von Objekten in Dateien und für die Übertragung von Objekten über das Netzwerk bei verteilten Softwaresystemen verwendet.

Übliche Speichermedien sind nur in der Lage, Datenströme zu speichern. Serialisierung für die Persistenz von Objekten. Hier wird der komplette Zustand des Objektes, inklusive aller referenzierten Objekte, in einen Datenstrom umgewandelt, der anschließend auf ein Speichermedium geschrieben wird.

Nach der Serialisierung liegt ein Objekt mehrfach vor. Sowohl in der externen Darstellung, beispielsweise als Datei als auch im Arbeitsspeicher. Wird nach der Serialisierung eine Änderung am Objekt im Arbeitsspeicher vorgenommen, hat dieses keine Auswirkung auf das serialisierte Objekt in der externen Darstellung.

Die Umkehrung der Serialisierung, also die Umwandlung eines Datenstroms in Objekte, bezeichnet man als Deserialisierung.

In der Linguistik bezeichnet man mit Serialisierung die Art und Weise, wie hierarchische grammatikalische Strukturen in eine lineare Abfolge gebracht sind, damit sie in einer zeitlichen Abfolge sprachlicher Ausdrücke dargestellt werden kann. Diese Reihenfolge kann in verschiedenen Sprachen unterschiedlich sein.

Eine kurze Zeitreise

JSON entstand aus der Notwendigkeit heraus, ein zustandsloses (stateless) Echtzeit-Kommunikationsprotokoll zwischen Server und Browser zu haben, ohne Browser-PlugIns wie Flash oder Java-Applets zu verwenden, die sich Anfang der 2000er Jahre als vorherrschende Methoden, im Einsatz befanden.

Crockford spezifizierte und verbreitete als Erster das JSON-Format. Das Akronym stammt von State Software, ein von Crockford und anderen im März 2001 gegründetes Unternehmen. Die Gründer hatten sich geeinigt, ein System zu entwickeln, dass Standard-Browser-Funktionen nutzte und eine Abstraktionsschicht für Web-Entwickler bereitstellte, um zustandsbehaftete (abstraction layer) Web-Anwendungen zu erstellen, die über eine dauerhafte Duplex-Verbindung zu einem Web-Server verfügten. Sie hielten dafür zwei Hypertext Transfer Protocol (https)-Verbindungen offen und bauten die Verbindung wieder auf, bevor die Standard-Browser-Timeouts eintraten, wenn kein Datenaustausch stattfand. Die Gründer stimmten darüber ab, ob das Datenformat JSML (JavaScript Markup Language) oder JSON (JavaScript Object Notation) genannt und unter welcher Lizenz die Verfügungstellung stattfinden sollte. Die Website JSON.org ging dann im Jahr 2002 online. Im Dezember 2005 begann Yahoo! damit, die ersten Webdienste (Web-Services) in JSON anzubieten.

Vorgänger geht auf ein Spiel für Kinder

Ein Vorläufer der JSON-Bibliotheken wurde in einem Projekt für Kinder, einem digitalen Trading-Spiel namens Cartoon Orbit bei Communities.com (Die Gründer von State hatten alle zuvor bei diesem Unternehmen gearbeitet), für Cartoon Network verwendet, dass ein browserseitiges Plugin mit einem proprietären Nachrichtenformat zur Manipulation von DHTML-Elementen nutzte (Dieses System gehört übriges 3DO). Nach der Entdeckung der frühen Ajax-Fähigkeiten verwendeten digiGroups, Noosh und andere, Frames, um Informationen in das visuelle Feld des Browsers zu übertragen, ohne den visuellen Kontext einer Webanwendung aktualisieren zu müssen. So hatten sie Rich-Web-Anwendungen in Echtzeit erstellt, die nur die Standard https-, HTML– und JavaScript-Fähigkeiten von Netscape 4.0.5+ und IE 5+ verwendeten. Crockford fand darauf heraus, dass JavaScript als objektbasiertes Nachrichtenformat für ein solches System verwendet werden kann. Das System wurde später an Sun Microsystems, Amazon.com und EDS verkauft.

JSON basiert teilweise auf JavaScript und wird häufig auch mit JavaScript verwendet. Dennoch ist es ein sprachunabhängiges Datenformat. Code zum Parsen und Generieren von JSON-Daten ist in vielen Programmiersprachen leicht verfügbar. Auf der JSON-Website sind die JSON-Bibliotheken nach Sprachen geordnet.

Im Oktober 2013 veröffentlichte Ecma International die erste Ausgabe seines JSON-Standards ECMA-404. Im selben Jahr verwendete RFC 7158 ECMA-404 als Referenz. 2014 wurde RFC 7159 zur Hauptreferenz für die Verwendung von JSON im Internet und löste RFC 4627 sowie RFC 7158 ab (wobei ECMA-262 und ECMA-404 als Hauptreferenzen beibehalten wurden). Im November 2017 veröffentlichte ISO/IEC JTC 1/SC 22 ISO/IEC 21778:2017 als internationalen Standard. Am 13. Dezember 2017 hat die Internet Engineering Task Force RFC 7159 durch die Veröffentlichung von RFC 8259, der aktuellen Version des Internet-Standards STD 90, überholt (ersetzt).

Crockford fügte der JSON-Lizenz eine Klausel hinzu, die besagt, dass „die Software für das Gute, nicht für das Böse verwendet werden soll“, um die JSON-Bibliotheken zu öffnen und sich gleichzeitig über Unternehmensjuristen und diejenigen lustig zu machen, die übermäßig pedantisch sind. Ironischer- und lustigerweise führte diese Klausel zu Konflikten der JSON-Lizenz mit anderen Open-Source-Lizenzen, da Open-Source-Software und freie Software in der Regel keine Einschränkungen hinsichtlich des Verwendungszwecks implizieren.

Wie ist JSON aufgebaut?

Die Daten können beliebig verschachtelt werden, beispielsweise ist ein Array (indizierte Liste) von Objekten möglich, die wiederum Arrays oder Objekte enthalten. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8. Auch UTF-16 und UTF-32 werden unterstützt.

JSON und die Typen von Elementen

• null = Nullwert (Wird durch das Schlüsselwort null dargestellt.)
• Boolean = Boolescher Wert (Wird durch die Schlüsselwörter true und false dargestellt. Dies sind keine Zeichenketten. Sie werden daher, wie null, nicht in Anführungszeichen gesetzt.
• Number = Zahl (Ist eine Folge der Ziffern 0–9. Diese Folge kann durch ein negatives Vorzeichen – eingeleitet und durch einen Dezimalpunkt . unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein optionales Vorzeichen + oder – und eine Folge der Ziffern 0–9 folgt.)
• String = Zeichenkette (Eine Folge von null oder mehr Unicode-Zeichen. Es beginnt und endet mit doppelten geraden Anführungszeichen („). Es kann Unicode-Zeichen und durch \ eingeleitete Escape-Sequenzen enthalten.
• Array = Anordnung (Beginnt mit [ und endet mit ]. Es enthält eine durch Kommata geteilte, indizierte Liste von Elementen gleichen oder verschiedenen Typen. Leere Arrays sind ebenfalls zulässig.
• Object = Objekt (Beginnt mit { und endet mit }. Es enthält eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften. Objekte ohne Eigenschaften („leere Objekte“) sind ebenfalls zulässig. Das Objekt besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt (Schlüssel : Wert). Die Schlüssel sollten eindeutig sein, da unterschiedliche Parser mit mehrfach vorkommenden Schlüsseln unterschiedlich umgehen. Während ECMA-404 keine Eindeutigkeit voraussetzt, fordert RFC 7159, dass Schlüssel innerhalb eines Objekts eindeutig sind. Folglich ist der Schlüssel eine Zeichenkette und der Wert ein beliebiges Element.

Nicht signifikante Leerraum-Zeichen sind erlaubt, also Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009), Zeilenumbrüche mittels LF und / oder CR (U+000D und U+000A). Diese Zeichen werden außerhalb von Zeichenketten bei der Interpretation ignoriert.

Die Grenzen von JSON

JSON unterstützt nicht alle von JavaScript unterstützten Datentypen. Bei nicht unterstützten Datentypen wird folgendermaßen serialisiert:

• NaN, Infinity und -Infinity werden zu null serialisiert.
• Date-Objekte werden in eine Zeichenkette konvertiert, die einer Datumsformatbeschreibung nach ISO-8601 genügt.
• Function-, RegExp- und Error-Objekte werden verworfen.

Das folgende Beispiel zeigt eine mögliche JSON-Darstellung zur Beschreibung meiner Person.

{
  "Unternehmen": "COEZBAY",
  "Nummer": "2023-23-23-777",
  "Waehrung": "BTC",
  "Inhaber": "CEO"
  {
    "Name": "Oezbay",
    "Vorname": "Cagatay",
    "maennlich": true,
    "Hobbys": ["IT", "Schach", "Basketball"],
    "Alter": 38,
    "Kinder": [],
    "Partner": null
  }
}

Das JSON-Schema

Das JSON-Schema gibt ein JSON-basiertes Format an, um die Struktur von JSON-Daten für die Validierung, Dokumentation und Interaktionssteuerung zu definieren. Es enthält einen Contract für die JSON-Daten, die für eine bestimmte Anwendung erforderlich sind und wie diese Daten geändert werden können.

Das Schema basiert auf den Konzepten des XML-Schemas, ist jedoch JSON-basiert. Wie in XSD (XML Schema Definition) können dieselben Serialisierungs- und Deserialisierungsprogramme sowohl für das Schema als auch für die Daten verwendet werden. Es ist selbstbeschreibend und in einem Internet-Entwurf der Internet Engineering Task Force festgelegt. Für verschiedene Programmiersprachen stehen mehrere Validatoren mit jeweils unterschiedlichen Konformitätsstufen zur Verfügung.

Der Vergleich mit XML

Sowohl JSON als auch XML beschreiben die Struktur eines Datensatzes. Der Datensatz kann weitere Datensätze enthalten. Dadurch sind beliebig tief verschachtelte Strukturen möglich.

In XML sind die einzelnen Knoten der Datenstruktur benannt, während die Knoten in JSON unbenannt bleiben.

Einfache Zeichenketten in XML können sowohl als Attribut eines Elements als auch als eigenständiges Element beschrieben sein. In JSON gibt es diese Unterscheidung nicht. Diese in den meisten Fällen irrelevante Flexibilität führt dazu, dass sich die Struktur von XML-Dokumenten häufig unnötigerweise unterscheidet.

Sowohl für JSON als auch für XML gibt es Beschreibungssprachen, um weiter einzugrenzen, wie „gültige“ Dokumente auszusehen haben. Ganz im Gegensatz zu „wohlgeformten“ Dokumenten.

Die Syntax von JSON ist einfacher gestaltet und erscheint daher oft lesbarer und insbesondere leichter schreibbar. In der Regel produziert JSON auch einen geringeren Overhead im Vergleich zu XML.

Sowohl JSON als auch XML müssen von einem speziellen Parser eingelesen werden. Traditionell ist jedes wohlgeformte JSON-Dokument ein gültiger JavaScript-Ausdruck. Das unaufmerksame Interpretieren von JSON-Dokumenten mit eval() führt jedoch zu Sicherheitslücken, die nicht zu unterschätzen sind.

Sowohl JSON als auch XML sind nicht gut zum Repräsentieren von Binärdaten geeignet, da beide Datenformate als Grundelement zeichenbasiert sind und nicht bytebasiert.

Der Beitrag JSON – Schönheit der einfachen Datenübertragung erschien zuerst auf CEOsBay.

Wie Twitter soll Spill einen Live-Nachrichten-Feed bekommen, in dem Nutzer „Spills“ posten können. Es soll eine Steigerung zu Mastodon‘s „Toots“ darstellen. Es nennt sich also „Spill“.

Irgendwie hat man darauf gewartet, dass sich noch ein paar Alternativen zu Twitter durch ehemalige Mitarbeiter bilden werden, oder? 😉

Nach der Redewendung „Spill the tea“ (Tee verschütten) – Und so beziehen sich die beiden Gründer Alphonzo „Phonz“ Terrell und DeVaris Brown Terrell darauf mit ihrem visuellen Auftritt auf ihrer Website. Das Motiv einer Teetasse. Und auf ihrer Website trotzt ein Meme von Kermit dem Frosch, wie er genüsslich an dem Tee schlürft (Das Meme erlangte übrigens wahre Popularität auf Black Twitter).

Was es aber meines Wissens nach wirklich bedeutet, ist – Wenn man im amerikanischen Slang von „den Tee ausschütten“ spricht, meint man in der Regel, dass „die Wahrheit“ aka „Gosspip“ aka Klatsch und Tratsch über jemanden gesprochen wird.

Warum Twitter?

Vielleicht ist es meine verschobene Wahrnehmung oder ich habe Twitter eben mit einer völlig anderen Intention genutzt. Doch irgendwie hat mich der Klatsch und Tratsch nie interessiert. Solange es um keinen Inhalt ging, der die Spezies Mensch in irgendeiner technologischen Art und Weise weitergebracht hat, war es für mich schlichtweg uninteressant. Spaß hatte ich gewisser Weise bei dem ein oder anderen Meme. Bei dem der ein oder andere Politiker bzw. Unternehmer etwas aufgezogen wurde. Aber dies war es dann auch schon.

Ich nutze und habe Twitter primär dafür genutzt, um Echtzeitinformationen von den direkten Quellen zu beziehen. Wenn Programmierer beispielsweise beabsichtigten, eine neue Lösung zu publizieren oder wenn es mal einen Brennpunkt in der Politik gab. Dafür war Twitter in meiner Vorstellung einfach ideal und schnell.

Tea time oder Teeparty?

Spill möchte scheinbar auch eine Funktion mit dem Namen „Teaparty“ einbauen. Bei der Nutzer sowohl online als auch im realen Leben, Events veranstalten können und im Anschluss In-App-Boni erhalten. Die finden dann Verwendung um Beiträge zu boosten. Nutzer sollen zwar immer noch geboostete Beiträge kaufen, aber wenn man auf Spill etwas kreiert und es startet durch, soll dies angemessen honoriert werden. So, Terrell.

Abgesehen von der multikulturellen Schiene, die sie mit dem Satz „Eine Echtzeit-Konversationsplattform, die Kultur in den Vordergrund stellt“ einschlagen, interessiert mich Spill besonders wegen der Anbindung an die Blockchain. Spill will die Blockchain-Technologie nutzen, um aufzuzeichnen, wie Beiträge viral gehen.

Auch sollen die Nutzer hinter den Beiträgen für Ihren „Erfolg“ entschädigt bzw. belohnt werden. Den Gründern sei es auch wichtig, dass Spill von Anfang an Funktionen zur Monetarisierung von Kreativen zur Verfügung stellt. Da dies ihrer Meinung nach besonders bei multikulturellen Kreisen schwierig gewesen sein soll, um an das „verdiente“ Geld zu kommen. Dennoch weigert sich Terrell bewusst, Spill als Web3-Unternehmen zu bezeichnen.

Sie gehen davon aus, dass die Plattform in etwa sechs bis acht Wochen an den Start gehen kann. Spill hat noch nicht konkret kommuniziert, wie die Umsatzbeteiligung über die Blockchain aussehen wird oder welche Methoden Verwendung finden. Sie möchten aber klarstellen, dass die Auszahlung mit Fiat-Money, also echtem Geld, in US-Dollar erfolgt und nicht in einer Kryptowährung.

Kulturelles Engagement mit künstlicher Intelligenz?

Brown, der als CTO von Spill fungiert, möchte das Engagement des Unternehmens für die Würdigung der kulturellen Hintergründe ausweiten.

Er spricht beispielsweise eine Studie an, bei der von Afroamerikanern verfasste Tweets mit einer 1,5-fachen Wahrscheinlichkeit als beleidigend oder hasserfüllt eingestuft seien. Während Tweets, die mit AAVE (African American Vernacular English) verfasst wurden, mit 2,2-facher Wahrscheinlichkeit als beleidigend eingestuft seien.

Die künstliche Intelligenz soll den kulturellen Kontext, in einer bestimmten Sprache nicht verstehen können. Dies sei primär der Annahme zu verschulden, dass Entwickler hinter der künstlichen Intelligenz Menschen sind, die die sprachlichen Nuancen anderer Kulturen nicht verstehen. Besonders auch nicht versuchen, sie zu verstehen. Als 3-sprachig aufgewachsener technologieaffiner Mensch, der heute 4 Sprachen spricht, kann ich diese Aussage weitestgehend unterstützen.

Spill entwickelt die Lösung mit einem kleinen Team, mit weniger als 10 Personen und hat drei Berater aus den verschiedensten Bereichen. Darunter auch Dantley Davis, der ehemalige Designchef von Twitter. Andere umtriebige Twitter-Konkurrenten wie Hive hatten Sicherheitsprobleme, als sie diese Art von Produkt ohne ein starkes bzw. erfahrendes Team entwickelten. Die Gründer von Spill sind jedoch zuversichtlich, dass sie nicht in dieselbe Falle tappen werden.

Warteliste

Die Warteliste von Spill ist jetzt live. Nutzer können ihr Handle bereits heute reservieren und Updates vor dem Start der Plattform erhalten.

Fazit

Wie bereits angesprochen, war es zu erwarten, dass noch die ein oder andere Twitter Alternative von ehemaligen Mitarbeitern auftaucht. Besonders auch in Anbetracht der Strategie, die derzeit von Twitter selbst verfoglt wird, muss scheinbar auch hin und wieder das Wort Blockchain oder Kryptowährung fallen. Dennoch ist man meiner Meinung nach mit konkreten Aussagen eher vorsichtig, da es dem Krypto- als auch dem daran verbundenen NFT-Bereich nicht sonderlich gut geht. Es ist abzuwarten, was sich die Gründer einfallen lassen, wenn es um die Monetarisierung der Content Creator mit Fiat Geld geht. Spannend ist es allemal und mein Handle ist mit dem üblichen Pseudonym bereits reserviert.

Der Beitrag Spill – Die nächste Stufe der Echtzeit-Konversation? erschien zuerst auf CEOsBay.