[Discussie] Archiver: Scripting of handling?

[Mr.Mouse]

Hoi allemaal!

We zitten als groep programmeurs tegen een probleem aan te kijken. Ik heb de afgelopen jaren aan een tool gewerkt waarmee men vele (meer dan honderd)verschillende archiefbestanden (hoofdzakelijk van spellen waar geluiden, graphics enzo instaan) kan openen en de inhoud extraheren of vervangen.

Om makkelijk nieuwe formaten te kunnen toevoegen heb ik twee simpele scripttalen geschreven gedurende de 6 jaar dat ik er in de hobbyuren aan gewerkt heb. Zo kon ik dan via het schrijven van een scriptje ondersteuning van een nieuw formaat bereiken zonder daarvoor de hoofd executable te moeten aanpassen.

Echter, nu willen we een nog veel betere ( ) tool maken voor dit soort zaken. Met de "oude" tool kun je archieven ook aanpassen: je kunt bestanden in dat soort archieven vervangen. Helaas is het script en zijn engine niet zo krachtig dat het iets kan TOEvoegen of WEGnemen van zo'n archief, het kan alleen bestaande bestanden verVANGen.
Dit is geen probleem voor de gemiddelde gebruiker die een spel heeft gekocht en weleens voor de grap een texture in z'n spel wil vervangen met een texture met z'n naam erop. Het spel verwacht een archief dat een vast aantal files heeft, deleten/adden is natuurlijk uit den boze; een crash zou er zeker zijn als het archief opeens minder bestanden zou hebben.

Het is WEL een probleem programmeer technisch gezien, want feitelijk weet de oude engine helemaal niet hoe het archief formaat werkt. Het kan geen "New" functie aan, omdat het feitelijk een script programmaatje runt die bepaalde zaken kan destilleren uit zo'n archief, dat genoeg is om bestanden te extraheren of te vervangen, maar verder kan het niet.
De vraag is voor ons nu:
A. door gaan met een nieuw script, dat dit wel kan, maar hoe moet zo'n script eruit gaan zien?
Eigenlijk wil ik af van scripts, omdat die nooit echt krachtig genoeg zijn om alle formaten volledig te kunnen ondersteunen. Je kunt er voor kiezen om je scripttaal heel erg uitgebreid te maken, maar ja, dan ben je op een gegeven moment een nieuwe programmeertaal aan het schrijven, en dat is niet de bedoeling. Mijn idee is dan :
B. schrijf voor elk nieuw formaat een aparte handler (in ons geval geschreven in de programmeer taal Python) die gestandaardiseerde functies kent en waar de GUI gewoon altijd gebruik van kan maken. De onderliggende code is in elke handler dan wel anders, maar de functie-aanroepen zijn universeel. Dat kost meer tijd dan een simpel scriptje te schrijven, maar is wel veel effectiever en is hoog aanpasbaar.

Wat zijn de ideeen (als die er al zijn) over dit dillema? Ik vraag niet om kant en klare oplossingen, maar elke discussie kan iets opleveren!

Mike Zuurman AKA Mr.Mouse/XeNTaX

[_Thanatos_]

Ik zou voor handlers gaan. Deze kun je heel mooi OO implementeren en zoals je al zegt, de aanroep is altijd gelijk, zondat dat de executable weet waar het over gaat (black-box principe).

Ik zou er dan persoonlijk wel voor kiezen die handlers in DLL vorm te maken, omdat dan de taal waarmee zo'n handler geschreven is, niet meer relevant is, dat is met jouw idee volgens mij nog wel.

Daarnaast zou je een speciale handler kunnen schrijven die op zijn beurt weer een script uitvoert, zodat je gebruikers zelf ook "handlers" kunnen schrijven.

[Mr.Mouse]

_Thanatos_ schreef op 04 oktober 2003 @ 03:11:
Ik zou er dan persoonlijk wel voor kiezen die handlers in DLL vorm te maken, omdat dan de taal waarmee zo'n handler geschreven is, niet meer relevant is, dat is met jouw idee volgens mij nog wel.

Hmm, nu wil het geval dat ik in de oude versie inderdaad gebruik maak van een DLL die de scripts uitvoert, de engine zeg maar. En die kan in principe in de nieuwe versie ook aangeroepen worden om zo de al ondersteunde formaten te blijven ondersteunen in het nieuwe project.
Een andere programmeur doet echter nu de API/GUI en hij stapt juist liever af van het gebruik van DLL's omdat dit de multiplatform mogelijkheden van de tool sterk beinvloed (gebruik van dll's is windows-gebonden).

Het voordeel is wel inderdaad dat het niet uitmaakt of de handler nu in C++ of VB is geschreven. We schrijven het momenteel in Python. Python biedt eveneens de mogelijkheid om kleine executables te maken die kunnen worden aangeroepen met command line options. De handlers zouden dan als .exe/com formaat kunnen worden gemaakt. Idee? Dan zit je wel met het probleem dat je functies niet rechtstreeks kunt aanroepen en informatie aan ze door geven. Je bent dan gebonden aan de commandline opties. Hmm.

_Thanatos_ schreef op 04 oktober 2003 @ 03:11:
Daarnaast zou je een speciale handler kunnen schrijven die op zijn beurt weer een script uitvoert, zodat je gebruikers zelf ook "handlers" kunnen schrijven.

Als ik het goed begrijp bedoel je ongeveer wat nu het geval is in de laatste versie. Zoals gezegd maakt deze gebruik van een DLL welke de script-engine is. Er wordt bovendien nog een (simpele) scriptor bij het programma geleverd waar de gebruiker zelf de scripts mee kan schrijven en testen op archiefbestanden. Is dat idee wat je bedoelt?

[PrisonerOfPain]

Mr.Mouse schreef op 04 oktober 2003 @ 10:27:
[...]

Hmm, nu wil het geval dat ik in de oude versie inderdaad gebruik maak van een DLL die de scripts uitvoert, de engine zeg maar. En die kan in principe in de nieuwe versie ook aangeroepen worden om zo de al ondersteunde formaten te blijven ondersteunen in het nieuwe project.
Een andere programmeur doet echter nu de API/GUI en hij stapt juist liever af van het gebruik van DLL's omdat dit de multiplatform mogelijkheden van de tool sterk beinvloed (gebruik van dll's is windows-gebonden).

Dan her-compileer je ze toch als .o voor de *nix?

[Johannes]

Ik denk dat je jezelf moet afvragen of je wel van plan bent om handlers in andere talen dan Python te schrijven. Het is natuurlijk wel leuk om de mogelijkheid om te scheppen, maar als je het niet gebruikt is het alleen maar overbodig werk (You Aren't Gonna Need It). Als je dan toch ooit de behoefte voelt om in een andere taal een handler te schrijven (voor performance-redenen bijvoorbeeld), dan kun je dat programma met een kleine wrapper vanuit Python aanroepen.

[Mr.Mouse]

Zo, ik heb even weer tijd om online te zijn. Zo als het nu is heeft de hoofdprogrammeur in ieder geval alle oude archief formaatscripts (zo'n 145) via een zelf geschreven conversieprogramma omgezet in Python. De nieuwe Python-based open source versie ondersteunt dus nu al de oude scripts, maar heeft er handlers van gemaakt. Dit heeft het voordeel natuurlijk dat je makkelijker kunt sleutelen aan de uitvoering van zo'n handler. Het nadeel ervan is dat je met de conversie in eerste instantie ook de script logica meeneemt, die wel aardig kan zijn als men een formaat toevoegd in dat script, maar omslachtig als je het helemaal in Python zou doen. In ieder geval ondersteunt het "forked-from-original" nieuwe open source project al de formaten van het origineel, wat we maar de legacy noemen. We kijken nu naar andere opties om toekomstige formaten te ondersteunen met meer flexibiliteit en mogelijkheden.

@Johannes, dat wrappen is inderdaad een goed idee, mocht de noodzaak daar zijn.