Kann man einen Record in einem String speichern?

[Sinspin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1497052)

:(
Aber das ist doch sooo meta.

Das dachte ich mir auch lange Zeit. Alles kurz und knapp in records gepackt und in Dateien geschrieben oder durch die Gegend kopiert.
Mittlerweile verschicke ich so oft Daten über Netzwerk oder Pipes das ich ohne irgend einen standartisierten Container verzweifeln würde.
JSON ist nicht ganz meins. Ich verwende eine Komponente die auf eine Memtable aufsetzt.
Die Komponente kann man als Zeiger anhängen oder übergeben. Strings oder Dynarray verwende ich zum Transport, erzeugen und intepretieren macht die Komponente selber. Klappt wunderbar.

[Rollo62]

Zitat:

Zitat von Sinspin (Beitrag 1497070)

JSON ist nicht ganz meins.

Ja OK, es hat aber den Vorteil das es die ganze Welt draussen verstehen kann.
Ist ein einfacher String, kann alles Mögliche packen, und ist dabei relativ flott.

Für alle einigermaßen normalen Anwendungsfälle würde ich das schon als erste Wahl in Betracht ziehen,
oder man baut sich halt was Eigenes was hier und da mal klemmt und womöglich nur einen Bruchteil der Möglichkeiten hat.

Und für die Binärfans gibt es ja noch BSON :-)

[himitsu]

Auch XML gibt es in binär oder zumindestens "komprimiert" (gleiche "Wörter", wie z.B. Namen der Nodes und Attribute werden zusammengefasst) ... hat sich nur nicht so richtig durchgesetzt ... ist halt nicht menschenlesbar.

[KodeZwerg]

Etwas weit hergeholt aber vielleicht dennoch brauchbar? (da ich gerade nicht genau weiß wo du da was wie verdrahten wolltest)

Dein Record/Object im Speicher komprimieren (per ZLib als Beispiel), diesen Stream per Base64 in einen String wandeln, an dein ListItem ranheften, bei abruf auf umgekehrten weg zurück.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1497109)

Auch XML gibt es in binär oder zumindestens "komprimiert" (gleiche "Wörter", wie z.B. Namen der Nodes und Attribute werden zusammengefasst) ... hat sich nur nicht so richtig durchgesetzt ... ist halt nicht menschenlesbar.

Ja richtig, JSON hat XML meiner Meinung nach abgelöst, weil es das Gleiche kann, aber kleiner und besser lesbarer ist.
Vielleicht gibt es eine Erhebung wieviel JSON/XML genutzt wird.
Ich vermute insbesondere im Web gibt es fast 95% JSON zum Datenaustausch, und kaum XML,
nur auf Desktop wird XML wohl noch öfters benutzt, auch als Dokumentenformate.

[himitsu]

Das Gleiche nicht ganz.
XML kann man anders verschachteln, z.B. Attribute und SubNodes zusammen im Node.
Und dadurch, dass vieles Doppelt vorkommt (schließender Node), ist hier die Fehlerbereinigung etwas einfacher möglich.
(nja, wie an den Heuristiken für HTML vs. XHTML in vielen Browsern geht's so lala)

Es gibt auch JSON-artig verschachteltes INI-artiges (INI selber hat ja praktisch keine Standards),
welche für manuelle Änderungen einfacher sind,
nur mit dem Nachteil, wie in Python, also die Gruppen haben kein Ende, allerdings wird mit unsichtbaren Zeichen (Einzückung) gearbeitet,
aber dafür raucht nicht gleich alles komplett ab, wenn in einer/mehreren Zeile(n) ein Syntaxfehler*innen steckt.



Wenn es nur um die Größe ginge (OK, ein gzip/ZLib drüber macht auch alles nochmal kleiner),
dann dürfte das binäre XML womöglich kleiner sein, als BSON.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1497133)

Das Gleiche nicht ganz.

Ja sicher, Du weisst schon was ich meine :stupid:
XML wird gerne bei .docx und Adobe benutzt, aber das ist dann schon mehr als nur ein einfacher Datenaustausch.

Ich sehe JSON mittlerweile als Default-Austauschformat for "normale" Zwecke,
so wie früher die INI-Datei.

[Frickler]

XML kann über Schema automatisiert validiert werden. Die nötigen Programme sind seit vielen Jahren standardisiert. Und sowas wie XSLT und XSL-FO fehlt auch unter JSON. man ist zwar dabei, das hier und da nachzurüsten, hat damit aber keine Eile. Denn JSON ist ein Format für Datenübertragung, nicht so sehr für Dateien.

Hingegen sehe ich als "Nachfolger" der INI Datei heute eher SQLite.

[Rollo62]

Zitat:

Zitat von Frickler (Beitrag 1497147)

Hingegen sehe ich als "Nachfolger" der INI Datei heute eher SQLite.

:thumb:

[himitsu]

So lange das Ding dann nicht auch mal schnell ohne Hilfsmittel per Hand bearbeitet werden soll. :stupid: