Applicatie compatible houden

[Alain]

Ik heb een applicatie gemaakt en ben daarbij een gui aan het maken. Naast de standaard mogelijkheden van mijn progsel (comprimeren van een tank tabel) is het in de gui mogelijk om projecten aan te maken. Een project bevat verschillende entiteiten zoals instellingen, groepen, tanks.

Ik wil het project binair opslaan met alle reeds gecomprimeerde informatie. Daarnaast wil ik een functie maken om het project naar XML te exporteren, zodat een latere versie van mijn applicatie om kan gaan met projecten uit eerdere versie's. Ik heb netjes een DTD gemaakt voor mijn project en alle objecten binnen het project. Ik vraag me alleen af wat een standaard werkwijze hiervoor is.

Wat gebruik jij om bestanden die je applicatie genereert compatible te houden met eerdere versie's van je applicatie (of andersom)?

[leuk_he]

Niet de standaard classes mogelijkheden gebruiken om de opject naar disk te serializeren, maar zelf een formaat daarvoor specificeren, waarin voorin ergens een versie nummer staat?

Als je toch een XML versie maakt die compatibel is met hogere (en lagere, dat is wel zo fijn?) versies doe je uiteraard dubbel werk als je ook nog een binair formaat bijhoud. (tenzij het om VEEL data gaat waar XML sterk vertraagt)

[Alain]

leuk_he schreef op zondag 18 januari 2009 @ 23:18:
Niet de standaard classes mogelijkheden gebruiken om de opject naar disk te serializeren, maar zelf een formaat daarvoor specificeren, waarin voorin ergens een versie nummer staat?

Dan kun je alsnog alleen het formaat openen van een bepaalde versie?

Als je toch een XML versie maakt die compatibel is met hogere (en lagere, dat is wel zo fijn?) versies doe je uiteraard dubbel werk als je ook nog een binair formaat bijhoud. (tenzij het om VEEL data gaat waar XML sterk vertraagt)

Het gaat om relatief veel data (2.8MB binair + overhead). Als ik de gecomprimeerde data ook bij ga houden (wat niet ondenkbaar is) zal het nog meer worden. In de export van het project laat ik de gecomprimeerde data weg, dus deze bevat alleen initiele informatie.

[CH4OS]

AlainS schreef op zondag 18 januari 2009 @ 23:26:
Dan kun je alsnog alleen het formaat openen van een bepaalde versie?

Hoe had jij dan backwards compatability in gedachten met oudere versies? Maar ik denk dat je leuk_he verkeerd interpreteerd.

Hij bedoeld, net zoals ik in gedachten had, dat je ergens aangeeft welke versie dat is, zodat de applicatie weet als zijnde welke versie hij het bestand moet interpreteren. Dat kan je denk ik het beste doen in je DTD en anders in de XML-file zelf natuurlijk.

[ Voor 40% gewijzigd door CH4OS op 18-01-2009 23:37 ]

[leuk_he]

AlainS schreef op zondag 18 januari 2009 @ 23:26:
[...]
Dan kun je alsnog alleen het formaat openen van een bepaalde versie?

Dan weet je toekomsitge applicatie hoe hij oude data moet interpreteren.

Wat voor omgeving (taal/libraries) praten we eigenlijk?

[Alain]

leuk_he schreef op zondag 18 januari 2009 @ 23:40:
[...]


Dan weet je toekomsitge applicatie hoe hij oude data moet interpreteren.

Dat is inderdaad een idee. Is dit de manier waarop jij project bestanden inleest?

Wat voor omgeving (taal/libraries) praten we eigenlijk?

Java en standaard libs.

[Alain]

GJtje schreef op zondag 18 januari 2009 @ 23:34:
[...]
Hij bedoeld, net zoals ik in gedachten had, dat je ergens aangeeft welke versie dat is, zodat de applicatie weet als zijnde welke versie hij het bestand moet interpreteren. Dat kan je denk ik het beste doen in je DTD en anders in de XML-file zelf natuurlijk.

Volgens mij heeft leuk_he het over de binaire bestanden en dat de applicatie onderscheid maakt in het in te lezen bestand. Mijn XML oplossing zou beide kanten op kunnen werken omdat de applicatie geen weet hoeft te hebben van nieuwe informatie.

[leuk_he]

AlainS schreef op zondag 18 januari 2009 @ 23:55:
[...]


Volgens mij heeft leuk_he het over de binaire bestanden en dat de applicatie onderscheid maakt in het in te lezen bestand. Mijn XML oplossing zou beide kanten op kunnen werken omdat de applicatie geen weet hoeft te hebben van nieuwe informatie.

Dat gaf ik ook al aan, Als je toch in (soms) XML gaat schrijven dan alles maar xml upward and downard compatible. anders zit je code voor binair EN xml te schrijven is dubbelop.

Hoe ik het heb gedaan is met tagged (niet xml,binair) formaat, maar dat is meer omdat ik dat zo kreeg.

bytes:
<tag><type><size (afhangelijk van type 1, tot 4 bytes)><data> (waarbij data ook weer een stucture van tags kon zijn)

Door in ieder geval size info in je data mee te save kun je later je formaten uitbreiden zonder dat alles incompatible hoeft te worden. echter alleen met een hex-editor te lezen en controleren...

Echter XML is simpler. zipped XML lost het probleem van size overhead van XML op (ok, kost wat extra cpu cycles... ).

[ Voor 3% gewijzigd door leuk_he op 19-01-2009 00:13 ]

[Alain]

leuk_he schreef op maandag 19 januari 2009 @ 00:13:
[...]


Dat gaf ik ook al aan, Als je toch in (soms) XML gaat schrijven dan alles maar xml upward and downard compatible. anders zit je code voor binair EN xml te schrijven is dubbelop.

Het is idd dubbelop, maar een binair bestand is vele malen sneller dan een export bestand. Ik wil het project compatible houden, niet het bestand of de applicatie.

Hoe ik het heb gedaan is met tagged (niet xml,binair) formaat, maar dat is meer omdat ik dat zo kreeg.

bytes:
<tag><type><size (afhangelijk van type 1, tot 4 bytes)><data> (waarbij data ook weer een stucture van tags kon zijn)

Door in ieder geval size info in je data mee te save kun je later je formaten uitbreiden zonder dat alles incompatible hoeft te worden. echter alleen met een hex-editor te lezen en controleren...

Vind je dat handig?

[leuk_he]

AlainS schreef op maandag 19 januari 2009 @ 01:03:
[...]
Vind je dat handig?

Ik vind binaire formaten zonder meer niet handig. debugged onhandig en maakt het nog eens extra complex als je naar andere acrhitecturen gaat.

[Janoz]

Het big/little endian gezeik is inderdaad af en toe behoorlijk lastig. Wat misschien een mooie tussenoplossing is, is om een gezipt xml-formaat te gebruiken. Je hebt dan een gestructureerd, makkelijk compatible te houden en debugbaar formaat, maar door te zippen hoeft het vervolgens niet zo groot te worden. Je hebt dan de voordelen van beiden. Voor het zippen zijn in alle omgevingen wel standaard oplossingen te vinden.

[Confusion]

AlainS schreef op zondag 18 januari 2009 @ 23:10:
Ik heb netjes een DTD gemaakt voor mijn project en alle objecten binnen het project.

Ik zou XML Schema pakken, dat is nauwkeuriger, completer en daarbinnen kan je ook veel makkelijker versioneren. DTD's zijn eigenlijk gewoon deprecated.

[MSalters]

Janoz schreef op maandag 19 januari 2009 @ 10:41:
Het big/little endian gezeik is inderdaad af en toe behoorlijk lastig.

Nergens voor nodig, als je simpelweg byte-oriented representaties gebruikt. Zoals base-128 varints (o.a. in Google Protocol Buffers)

[Hydra]

MSalters schreef op maandag 19 januari 2009 @ 12:55:
Nergens voor nodig, als je simpelweg byte-oriented representaties gebruikt. Zoals base-128 varints (o.a. in Google Protocol Buffers)

AFAIK gebruikt Java sowieso gewoon network byte order dus zou je geen last moeten hebben van big/little endian problemen tenzij die data zelf van een systeem afkomt waar het wel een probleem is. Maar dan is het een kwestie van het eerst even converteren voordat je het opslaat.

[Alain]

Janoz schreef op maandag 19 januari 2009 @ 10:41:
Het big/little endian gezeik is inderdaad af en toe behoorlijk lastig. Wat misschien een mooie tussenoplossing is, is om een gezipt xml-formaat te gebruiken. Je hebt dan een gestructureerd, makkelijk compatible te houden en debugbaar formaat, maar door te zippen hoeft het vervolgens niet zo groot te worden. Je hebt dan de voordelen van beiden. Voor het zippen zijn in alle omgevingen wel standaard oplossingen te vinden.

Dat is wel een goede, daar had ik zelf nog niet aan gedacht.

Confusion schreef op maandag 19 januari 2009 @ 10:46:
[...]

Ik zou XML Schema pakken, dat is nauwkeuriger, completer en daarbinnen kan je ook veel makkelijker versioneren. DTD's zijn eigenlijk gewoon deprecated.

Thnx voor de opmerking, dat had ik niet in de gaten. Ik zal het vanavond even omzetten.

Hydra schreef op maandag 19 januari 2009 @ 17:16:
[...]


AFAIK gebruikt Java sowieso gewoon network byte order dus zou je geen last moeten hebben van big/little endian problemen tenzij die data zelf van een systeem afkomt waar het wel een probleem is. Maar dan is het een kwestie van het eerst even converteren voordat je het opslaat.

Ik zal er toch rekening mee moeten houden, want ik wil ook een paar binaire bestanden uitpoepen die ik in een PLC wil laden. Ik maak het sowieso instelbaar, omdat niet elke PLC gelijk is.