formaat voor serialiseren bepalen

[dodona-edu]

formaat voor serialiseren bepalen

[niknetniko]

Huidige stand van zaken:

Datatypes

Een lijst van data die we willen ondersteunen (kan later uitgebreid worden):

1. Primitieven:
   1. Gehele getallen (integer)
   2. Reële getallen (real)
   3. Boolese waarden (boolean)
   4. Tekenreeksen (string)
2. Collecties
   De waarden zelf hebben een type van deze lijst, niet noodzakelijk allemaal hetzelfde.
   1. Rij (list)
      Dit is de wiskundige rij: een eindige, geordende reeks waarden.
   2. Verzameling (set)
      Dit is een wiskundige verzameling: een eindige, niet-geordende reeks waarden.
   3. Een afbeelding (map). Ook dict of associatieve array.
      Dit is de wiskundige afbeelding: elke element (de sleutel) wordt afgebeeld op een ander element (de waarde).
      Merk op dat een map met opeenvolgende gehele getallen als sleutels niet in alle talen te onderscheiden is van een rij.

Welke datatypes worden bewust (nog) niet ondersteund:

1. Gespecialiseerde types van een van bovenstaande types, zoals bewerkbaar of niet (bv. tuples). Ook implementatiedetails worden niet ondersteund (bv. gelinkte lijst vs. array).
2. Objecten, klassen of structs:
   • Methoden kunnen getest worden met normale testgevallen.
   • Attributen/velden kunnen getest worden door het object of de klasse als map door te sturen.
3. Bomen.
   • Kan voorlopig met maps en lijsten.
   • Misschien later wel ondersteuning.
4. Oneindige reeksen of verzamelingen, bv. ook generators.
5. Individuele tekens (bv. char): gebruik een string van lengte 1.
6. Binaire waarden (bv. byte): codeer het zelf en sla op als string (bv. met base64).
7. Andere interpretaties van een string. Al deze dingen kunnen door ondersteuning toe te voegen voor een gespecialiseerde evaluator.
   1. Regexen: als de data moet voldoen aan een regex
   2. Datum/tijd

Codering

Twee grote denkpistes:

1. Een bestaand schema voor de data vinden. Hiermee bedoel ik niet enkel syntactische definities (welk formaat; json, xml, binair, enz.), maar ook semantische definities (een lijst van getallen wordt bv. op een bepaalde manier gecodeerd). Hierbij moet het schema voldoen aan volgende vereisten:
   • Ondersteuning voor de gewenste datatypes.
   • Datatypes zijn uitbreidbaar: als we nieuwe datatypes willen ondersteunen, dan gaat dat.
   • Eenvoudig te schrijven: het schrijven in dit formaat moet eenvoudig zijn, zodat nieuwe talen snel toegevoegd kunnen worden.
2. Zelf een schema opstellen en een bestaande codering gebruiken.
   • Het ligt voor de hand om dan json te gebruiken: xml is niet zo compact en binaire formaten zijn moeilijk naar te schrijven.

We hebben alle formaten van op X overlopen.

Bestaand schema

Veel formaten hebben geen ondersteuning voor alle datatypes. Een formaat dat (bijna) alle types ondersteunt is ASN.1. Dit is een formaat specifiek om data op te slaan (en heeft niets te maken met RPC). Enkele kenmerken:

• ASN.1 zelf is een abstract formaat voor het schema.
• De eigenlijke waarden worden geserialiseerd door middel van de "encoding rules". De meest gebruikte en oudste zijn die in binaire waarden (DER).
• Er bestaan ook "encoding rules" voor xml, json en gewoon strings.

Ondersteuning:

• Door de ouderdom meestal wel iets van ondersteuning: vaak wel enkel binair formaat.
• In Python bestaat een library die een heleboel formaten kan aanvaarden.
• Niet onmiddellijk duidelijk hoe lang het zou duren om een eigen "encoding rule" naar bv. json of strings te implementeren.
• Als we binair willen ondersteunen, moeten we sowieso ook base64/base128 hebben; de uitvoerformaten zijn namelijk niet binair.

Een schema is mogelijk (compilers bestaan, gelijkaardig aan hoe bv. protobuf werkt), maar niet noodzakelijk.

Eigen schema

Het is uiteraard mogelijk om met json-schema een eigen schema op te stellen voor de onze datatypes.

Bij het zelf opstellen van het schema is het uiteraard ook mogelijk om andere dingen als protobuf te gebruiken, maar de vraag rijst waarom we dit zouden doen:

• Heeft compiler nodig, niet triviaal om te implementeren.
• Binair is altijd lastiger als we het dan toch zelf moeten doen.

Het eerste punt is niet altijd waar; bv. flatbuffers kan in "schemaloze" modus gebruikt worden, maar dan nog moeten we werken met binaire waarden.

[niknetniko]

Na overleg is gekozen voor een eigen formaat in json, zie #6.