Sauf pour les libs dynamiques, si tu gères ça manuellement. Mais dans ce cas, autant gérer des plug-ins, non ?Sasume :
OK. Bonne initiative
Par contre, ce qui serait pratique, c'est qu'on puisse rajouter des formats facilement.
Soit en utilisant des plug-ins, mais l'utilisateur risque de se retrouver avec un tas de plug-ins. Quoique, il pourrait ne mettre que ceux qui l'intéressent (et je doute que qq1 s'amuse à compresser ses fichiers en différents formats ).
Soit en utilisant un fichier de conf. Mais là ça devient un peu compliqué pour gérer les cas où le fichier de conf est erroné, si on veut que le soft soit stable.
Sinon, on peut tout simplement mettre à jour ta lib en dur.... Mais cette méthode a le désavantage de regrouper le code de toutes les libs nécessaires pour compresser dans les différents formatsSauf pour les libs dynamiques, si tu gères ça manuellement. Mais dans ce cas, autant gérer des plug-ins, non ?
Flanker
: oué, mais les plugs-in, le désavantage, c'est devoir recoder les libs déjà existantes
Sasume
:Flanker
: oué, mais les plugs-in, le désavantage, c'est devoir recoder les libs déjà existantes
Je ne pense pas (mais j'ai peut-être mal réfléchi).
Je pense que le plug-in pourrait être simplement un front-end pour appeler les libs existantes, tout en fournissant une API qui convient à ta lib pour que tu puisses l'appeler.
En gros, chaque plug-in permettrait d'unifier l'API d'une (ou plusieurs) lib(s) déjà existante(s).
unsigned long get_magic(); // Permet d'identifier que cette lib est bien un plug-in de compresslib unsigned short compress_file(const char *file); unsigned short compress_folder(const char *folder); // (pour les dossiers on peut p-ê faire autrement) unsigned short get_type(const char *compressed_file); unsigned short uncompress(const char *file); // etc...
#include "unelib.h"
unsigned short compress_file(const char *file)
{
// Code utilisant la lib en question pour compresser
}
// etc...
// Par exemple, pour un plugin utilisant ziplib :
#include "ziplib.h"
unsigned short compress_file(const char *file)
{
SYM_ENTRY *sym_file = SymFindPtr(SYMSTR(file),0);
ziplib_compress(sym_file,0);
return ...;
}Sasume :
Par exemple, on pourrait dire que les plug-ins sont des progs kernel (plus précisément des libs à priori), exposant cette API (en considérant qu'un plugin fournit un seul format de compression) :unsigned long get_magic(); // Permet d'identifier que cette lib est bien un plug-in de compresslib unsigned short compress_file(const char *file); unsigned short compress_folder(const char *folder); // (pour les dossiers on peut p-ê faire autrement) unsigned short get_type(const char *compressed_file); unsigned short uncompress(const char *file); // etc...
Ensuite, chaque lib (plugin) contiendrait un code du genre :#include "unelib.h" unsigned short compress_file(const char *file) { // Code utilisant la lib en question pour compresser } // etc... // Par exemple, pour un plugin utilisant ziplib : #include "ziplib.h" unsigned short compress_file(const char *file) { SYM_ENTRY *sym_file = SymFindPtr(SYMSTR(file),0); ziplib_compress(sym_file,0); return ...; }
Sasume :
Ah ok, pour les formats de compression "non kernel", genre ppg ou xpak tu penses faire appel dans compresslib à superstart() ou xpak() ?
Je pensais que tu linkerais compresslib avec les les libs statiques qui permettent de décompresser le ppg ou le xpak...
Dans ce cas, c'est effectivement plus simple avec un fichier de conf.
Twindruff
:Flanker :
je vais peut-être devoir faire une lib kernel qui sache décompresser le ppg)
Einstein de thibaut savait décompresser les ppg.
#troll#
Twindruff :
Me prennez pas pour un mongol, je disais ça parceque Thibaut aurait pu te refiler son code, Flanker, si ça te faisait chier de le refaire.
Pollux
: et si j'ai bien compris le pb pour une API maison c'est que pour gérer le ghost space, à moins d'exiger HW*Patch il faut que l'appelant déclare un buffer vide assez grand pour contenir tout le code, non ?
tu as une idée du temps qu'il faut pour changer le masque ?Pollux :
pour xpak je compte exposer aussi une API plus bas niveau que la ligne de commande basic ^^ (en fait j'hésite entre mistub seulement et mistub+API nostub maison)
et si j'ai bien compris le pb pour une API maison c'est que pour gérer le ghost space, à moins d'exiger HW*Patch il faut que l'appelant déclare un buffer vide assez grand pour contenir tout le code, non ? (ce qui ne pose pas de pb pour un programme compressé, mais c'est plus embêtant pour un programme non compressé)
euh et sinon pour économiser la RAM il faudrait peut-être que tu utilises le chargement à la demande des libs ^^ (enfin ça dépend si tu comptes gérer 50 formats ou seulement 3)
, je disais ça parceque Thibaut aurait pu te refiler son code, Flanker, si ça te faisait chier de le refaire.