Discussion :

[Clorish]

Je cherche a creer un gestionnaire de bibliotheque pour faciliter la mise a jour constante de nos apis dans la boite

Mon but serait d'arriver a detecter la version des fichiers DCU present sur le Disque, en evitant si possible de changer de nom de DCU en fonction des versions :/ (MonUnit_V101 c pas top quoi )

De plus si vous aves des idees pour gerer un systeme de Mise a jour automatique (genre le "Check Update" present sur de nombreux logs ...)

Le truc a faire est de pouvoir supprimer les fichiers qui manquent, rajouter les nouveaux, et modifier ceux qui on changé.
Mais si la personne a rate une modif, il faut que le "patch" de mise a jour de la dernierre version qu'il va executer prenne en compte tous les changements depuis la version qu'il a (qui n'est peut etre pas l'avant derniere en date)

Grosso modo, faire la meme chose que les Logs de mise a jour des clients MMORPG comme World Of Warcfat, capable de mettre a jour les log de la Version 1.2.1 vers la 1.4 sans passer par les update 1.2.1->1.2.2 puis 1.2.2->1.3.0 et 1.3.0->1.4.0

Si un tel log existe deja je suis preneur

[Mac LAK]

Avec CVS, tu peux le faire automatiquement en incluant un "$Log" dans le source (dans des commentaires, en général), mais il faut que tu regardes la doc pour les détails.

[Clorish]

En fait CVS ne m'interesse pas pour cette partie.

Je cherche a faire un simple outils de mise a jour et de telephargement de version ou une methdoe de creation de patch pour "mettre a jour" via le net mon application.

Cette methode, je compte l'appliquer a plusieurs logiciels que nous distribuerons.

Le cas particulié presenté ici, c'est que l'une des premieres utilisation de ce log sera de generer des patch pour une application speciale : Une bibliotheque de composant/Apis Delphi.

Les fichiers mis a jour seront donc des DCU et BPL de Delphi.
J'ai donc sur un serveur la derniere viersion des DCU de la distribution "stable" ainsi que de celle dite "Testing".

Je souhaite que regulierement les developpeur puissent mettre a jour leur copie locale des DCU/Paquets en fonction de ceux present sur le Serveur et ce de maniere automatique.

Mon gros probleme reside dans le fait qu'il faudra peut etre supprimer des fichiers de temps en temps ... et non seulement des creation/Mises a jours.

[Mac LAK]

Si c'est sur les binaires, tu es TRES mal, étant donné que les DCU n'acceptent pas les informations de version Windows... Mis à part te fader une table de correspondance empreinte<->version, je ne vois pas comment tu peux t'en sortir de façon propre...
Ou alors, ça va être "turbo-bidouillesque", en incluant par exemple dans chaque unité une constante typée chaîne dans l'implémentation, contenant un marqueur connu + le numéro de version... Faudra alors scanner le DCU, chercher le marqueur et lire le numéro de version après. Méthode crade. Beurk. Pas beau.

Par contre, pour les BPL, c'est possible : même principe que pour versionner un exécutable, même si ça n'apparaît pas lors du hover sur le BPL dans l'explorateur. En gros, tu n'as qu'à demander la version du fichier en utilisant l'API Windows. J'ai un composant tout prêt (TFileVersion) sur mon site pour gérer ça, si tu veux aller un peu plus vite.

[Clorish]

Ouais .. c pas idiot de voir les choses comme ca : Distribuer bpl et DCU et tester quel est la version du BPL qui a compilé les DCU (en supposant bien sur que les DCU soient bie nceux que j'ai cree lors de la compilation du Bpl )

Pour ce qui est du checkVersion ok. Mais pour la mise a jour : Tu me conseilel quoi ? Parce que je souhaiterais que lorsque je rajoute une compo, Api dasn un de ces paquets, tous les developpeurs aient leurs paquets mis a jours lors du prochain chargement de L'IDE. Donc cela impique desinstalation des PAquets, suppression des paquets/DCU, telechargement des nouveaux PAquets/DCU, etc ...

Moi je pensais faire simple :
- 1 rep par theme
- Scanner les DCU pour chopper leur numero de version (meilleur des cas) ou calculer les CRC32 (pire des cas)
- Mettre a jour les fichiers DCU, telecharger les nouveaux, supprimer les anciens.

Mais le probleme c'est que si je reorganise les fichier (ok c pas top question dev mais parfois ca arrive ) je ne sais pas commetn dire que les fichiers doivent etre supprimé a moins d'une "jointure" sur 2 StringList une local et uen distante :/

En fait ce qui me pose le plus de probleme est le "saut de version" ... je ne peut donc pas supposé que le patch precedent a ete appliqué par tous ... et ca me fait un peu mal d'executer les N patches manqués (surtout en cas de reinstallation totale ....)

[sjrd]

J'ai une autre solution à te proposer :
Utilise un petit fichier texte sur ton serveur qui contienne le numéro de la version actuelle. Au lancement de Delphi par exemple (tu peux faire ça avec un petit expert assez facilement, surtout si t'as un bouquin qui en parle), tu vérifies grâce à ce fichier s'il faut faire une mise à jour.
Si c'est le cas, tu en informes l'utilisateur en lui disant de fermer Delphi (le prog de téléchargement se lancera tout seul bien sûr).
Tu fais un petit prog pour télécharger la mise à jour (sous forme de fichier d'installation, par exemple Inno Setup).
Une fois téléchargé, tu désinstalle l'ancienne version, puis tu installes la mise à jour.
C'est ce que je fais (plus ou moins) pour une de mes appli, qui a besoin d'être mise à jour.

[Mac LAK]

Pour ce qui est du checkVersion ok. Mais pour la mise a jour : Tu me conseilel quoi ? Parce que je souhaiterais que lorsque je rajoute une compo, Api dasn un de ces paquets, tous les developpeurs aient leurs paquets mis a jours lors du prochain chargement de L'IDE. Donc cela impique desinstalation des PAquets, suppression des paquets/DCU, telechargement des nouveaux PAquets/DCU, etc ...

Sinon, tu passes par les fichiers PCE (collections de paquets), c'est bourrin mais efficace. Je ne sais pas ce que ça donne du point de vue automatisation, par contre...

- Scanner les DCU pour chopper leur numero de version (meilleur des cas) ou calculer les CRC32 (pire des cas)

Pas de CRC32 : pas assez fiable. Au moins une empreinte MD5, histoire d'assurer, voire un SHA-1.

Mais le probleme c'est que si je reorganise les fichier (ok c pas top question dev mais parfois ca arrive ) je ne sais pas commetn dire que les fichiers doivent etre supprimé a moins d'une "jointure" sur 2 StringList une local et uen distante :/

Simple : la méthode du "patch total". En pratique, ça correspond à une liste de tous les fichiers courants et des fichiers passés. Pour chaque fichier, deux solutions :
- Une empreinte MD5 ou un numéro de version valide : Le fichier existe. Si les numéros de contrôle sont différents (pas de tests "plus récent ou pas", mais une simple différence avec la référence), alors tu mets à jour.
- L'empreinte est nulle, la version est 0.0.0.0 : le fichier n'existe plus (=> obsolète).
Ce système te permet même, ultérieurement, de "remettre" dans le circuit un nom de fichier qui avait été supprimé auparavant... Cool, non ? ;-) Ca te coûte un fichier à télécharger lors de la mise à jour (un .INI passé à LZEXPAND suffit amplement), puis un moteur d'analyse local sur le programme de mise à jour (pas dur).
Perso, j'aurais tendance à (pour une fois !!) privilégier XML :
- Stocker l'arborescence des fichiers en "miroir" dans le XML,
- Rajouter, pour chaque fichier ou répertoire, un flag de version (ou de simple existence pour les répertoires),
- Rajouter éventuellement des "tags" de déplacement si besoin est,
- Conserver les entrées des "vieux" fichiers dans le XML, de manière à pouvoir déplacer les copies locales si nécessaire,
- Pour chaque fichier modifié, vérifier son impact (besoin de réenregistrer/désinstaller dans Delphi ?) : si la mise à jour l'a modifié (que ce soit une suppression ou une MAJ), tu prends les actions nécessaires.

En faisant ça, un patch de "réorganisation" ne coûterait rien en téléchargement, hormis le fichier XML compressé correspondant (que des tags de déplacement/suppression => pas de downloads)... C'est clair pour toi ?

Par contre, j'aurais tendance à toujours stocker, en plus du numéro de version, l'empreinte MD5 ou SHA-1 du fichier... Par sécurité, au moins pour l'intégrité du transferts.

Une alternative pouvant être intéressante : considérant les fichiers comme étant dans un sous-répertoire, utiliser un outil comme QuickPar pour générer des fichiers de parité sur tes unités. Ensuite, localement, tu télécharges le "nouveau" fichier de parité (très petit fichier) : QuickPar va alors pouvoir vérifier l'intégrité des fichiers courants, et te dire combien de blocs manquent. Il suffit d'envoyer X blocs de parité (n'importe lesquels) pour reconstituer les nouveaux fichiers... C'est un truc génial, je crois que les sources sont librement disponibles en plus si tu as besoin de l'intégrer de manière transparente.
Liens :
http://parchive.sourceforge.net/
http://www.quickpar.org.uk/index.htm

[Clorish]

J'avais deja pense a mettre en place un System de PAtch total comme tu le preconise mais l'idee de garder en memoire la liste de tous les fichiers obsolettes me parraissait un peu lorde .. surtout pour gerer une bibliotheque de composants/Outils qui sera mis a jour regulierement avec pas mal de changements de noms/Suppressions de fichier le temps de stabiliser les unites. (je sais c pas propres ^^)

Donc je pense que je me tournerais verse cette solution quand meme car c'est la seulle qui gere facilement la liste de TOUS les fichiers presents potentielement sur le PC local et distant sans etre oblige de faire une fusion de listes.

Par contre tu parle d'un Fichier Ini passe a LZExpand ... je ne connait pas ca .. qu'est ce que c'est ? (pas le fichier ini mais LZExpand )

Pour ce qui est du XML j'ai deja pense l'utiliser pour pas mal de choses, mais j'ai pas rouve de composant vraiement interessant. quand je dit interessant c'est d'une part aussi simple a manipuler que les TIniFile mais aussi qui ne trianent pas avec lui 30 Fichiers unites suplementaires d'analyseurs ou je ne sais pas quoi :/ tu as un compos/Lib a me conseiller ?

Par contre je n'ai pas tres bien suivi ta derniere hypothese mais je pense que les liens m'eclairerons davantage.

Ha oui : LE CRC32 n'a pour le moment pas eu de consequences graves mais effectivement le MD5 ou SHA-1 sera a envisager dans ces cas la.

PCE : C quoi ca ^^ jamais entendu parlé ;p

SJRD >> Oui c'etait a la base mon concept mais justement c'est sur la gestion du "Desinstalation" qui me pose un chti probleme .... et puis comme l'as dit Mac-lak (et je suis d'accord ) ca allourdi les mises a jours en cas de simple reorganisation :/

[Laurent Dardenne]

Si les fichiers de ressources sont inclus dans les DCU il est peut être possible de détourner leur utilisation ?

[Clorish]

Si les fichiers de ressources sont inclus dans les DCU il est peut être possible de détourner leur utilisation ?

Qu'entends tu par la ?
Dois je comprendre qu'il est possible de generer un fichier de ressource avec un ressource string indiquand le num de version pour l'en extraire via le log de mise a jour ?
Si oui je ne vois pas comment ...
Mais je crois pas. j'ai souvent eu des pbs car lors de la compilation de mes compos, ils me demandais le Fichier Res. Un simple lien doit figurer.

[Laurent Dardenne]

Dois je comprendre qu'il est possible de generer un fichier de ressource avec un ressource string indiquand le num de version pour l'en extraire via le log de mise a jour ?

Oui

Si oui je ne vois pas comment ...

Pour l'instant moi non plus, c'était juste une idée comme ça à creuser et voir si ce n'est pas une impasse.
D'où le peut être dans ma formulation.

[Clorish]

Dans ce cas je ne pense pas que cela soit possible du fait que les Ressources demande un handl, qu'il est pas possible a mon sens de charger un dcu et d'obtenir un handle, que Delphi nous demande a la compilation les .Res (donc a priori non inclu dans les DCU) ...

MAsi si qqu trouve je susi preneur

[Mac LAK]

(je sais c pas propres ^^)

Bah, au moins t'en es conscient ! ;-)
Plus sérieusement, tu peux aussi inclure, dans ton fichier, un numéro de "version majeure" : en cas de changement de version majeure, tu obliges le gus à tout effacer, puis re-télécharger... Brutal, mais permet aussi de "faire le ménage" dans les fichiers effacés.

Par contre tu parle d'un Fichier Ini passe a LZExpand ... je ne connait pas ca .. qu'est ce que c'est ? (pas le fichier ini mais LZExpand )

Un module de compression intégré à Windows, genre ZLib. C'est celui qui fait des archives dont le 3ème caractère de l'extension est remplacé par un underscore. Tous les OS Windows ont la librairie de décompression, c'est donc peinard.
Sinon, une version statique de la ZLib conviendra aussi, ou LZO (même auteur)... En fait, on se fout de l'algo de compression utilisé, le but étant simplement d'avoir un fichier suffisamment cryptique pour ne pas être édité à la main, et suffisamment protégé pour qu'une corruption lors du téléchargement soit détectée à coup sûr (concaténer une empreinte MD5 au flux binaire compressé, par exemple).

Pour ce qui est du XML j'ai deja pense l'utiliser pour pas mal de choses, mais j'ai pas rouve de composant vraiement interessant. quand je dit interessant c'est d'une part aussi simple a manipuler que les TIniFile mais aussi qui ne trianent pas avec lui 30 Fichiers unites suplementaires d'analyseurs ou je ne sais pas quoi :/ tu as un compos/Lib a me conseiller ?

Hélas non, je n'en connais pas : je "boycotte" XML à cause de ça justement... Mais n'oublie pas que ça ne concerne que ton "créateur d'updates" et ton client de mise à jour : tu peux les compiler avec une version statique des unités requises (et donc te passer de DLL annexes). En encore, ça ne concerne réellement que le client !
Si le "créateur" requiert plein de fichiers pour fonctionner, ça n'est pas trop grave, étant donné qu'il est unique et maintenu/utilisé par quelqu'un connaissant son fonctionnement.
Le client, par contre, devrait être un exécutable autonome (et compressé par UPX au passage), unique, ne requérant rien de plus qu'une URL de téléchargement pour fonctionner.

Par contre je n'ai pas tres bien suivi ta derniere hypothese mais je pense que les liens m'eclairerons davantage.

Fichiers de parité : l'algo est assez infect à comprendre, mais en gros, un jeu de fichiers est divisé en blocs, protégés par des blocs de parité.
Là où c'est fort, c'est que quels que soients les blocs d'origine manquants ou endommagés, s'il te manque N blocs d'origine, il te suffit de N (ni plus, ni moins) blocs de parité distincts (n'importe lesquels !!!) pour reconstruire les blocs d'origine !!
Utilisé surtout pour la diffusion de binaires volumineux sur les newsgroups, où la perte de messages est très fréquente : on diffuse l'archive (100%), les blocs de parité (mettons +20%), et toute personne voyant au moins 84% des messages pourra reconstituer l'archive d'origine au lieu de pleurer pour un bloc/message systématiquement perdu.
Ca doit pouvoir être utilisé comme "patcheur", également, si les blocs sont de taille suffisamment réduite... Des essais sont à faire, je pense : si QuickPar permet de faire ce que tu veux, l'intégration du système PAR2 (sources SourceForge ou appel de programme externe suivant le cas) peut devenir intéressant...

PCE : C quoi ca ^^ jamais entendu parlé ;p

Delphi -> Outils -> Editeur de collections de paquets, puis le F1 magique...
Et une honte pour Clorish qui n'a pas lu toute la doc de Delphi, une !! ;-)

Pour les ressources dans les DCU, ça m'étonnerait que Windows accepte d'ouvrir un DCU comme un module...

[Clorish]

Bah, au moins t'en es conscient ! Wink

Ouaip !! Mais bon faut dire que pour commencer j'en aurais besoin pour mettre a jour les DCUs de nos librairies.
Le concept :
Upper sur un serveur nos lib/Compos sous forme de DCU/BPL.
Faire une copie locale de ces fichiers sur les pcs des developpeurs.
LE systeme de maintenance s'occupera a chaque Demmarage de Delphi de checker les Mise a jour des fichiers de maniere a mettre a jour automatiquement la copie locale des developpeurs a chaque fois que j'up une nouvelle version d'unitee avec des Ais/Compos en plus. Ca evite les transferts via MSN, les "je t'explique comment qu'on installe", et la mise a jour rapide et efficace des lib en cas de formatage HDD et reinstall Delphi.

Mais bon vu que pour le moment le Developpeur c moi..... donc ca gene pas trop si je suis bourrin au niveau suppression de fichier puisque le seul utilisateur c moi ;p
Ca me permet d'y voir plus clair aussi. Je developpe avec une copie locale des unitee fonctionneles, j'en ecrit une et la teste en locale, puis je le met sur le serveur uen fois stabilisé et elle se rajoute a ma copie locale juste apres.
Ainsi j'ai pas 36 lib, les stables, les dev, les non finies, etc ...
Ensuite ya les 2/3 stagiaires qui passent et le boss qui me rejoint en prog de tps en tps ... qui pourront se mettre a jour comme ca.

Et a plus long terme . .faudra l'adapter a la mise a jours de notre logiciel qu'on vendra .... (mais le principe restera foncierement le meme !!)

Un module de compression intégré à Windows, genre ZLib. C'est celui qui fait des archives dont le 3ème caractère de l'extension est remplacé par un underscore. Tous les OS Windows ont la librairie de décompression, c'est donc peinard.

Oki je me pencherais la dessus .. mais bon j'ai pas trop d'interet a ca tant que ca ne touche pas la mise a jour d'application commerciale mais reste interne a la societee pour la mise a jours des outils de production.

Hélas non, je n'en connais pas : je "boycotte" XML à cause de ça justement...

Moi aussi Finalement les fichiers Ini sont pas si mal que ca 0:-)

Fichiers de parité : l'algo est assez infect à comprendre, mais en gros, un jeu de fichiers est divisé en blocs, protégés par des blocs de parité.

Oki j'ai vue ca deja quelque part .... Ca me semble un peut lourd pour un systeme de mise a jour .. amoins que ca ne concerne de grosses applis.

Et une honte pour Clorish qui n'a pas lu toute la doc de Delphi, une !!

Gniagniagniagnia !!! J'ai dit que j'aimais bien cette pov' tit' aide delphi .. pas que je l'avais toute lue (et pis pour chercher .. faudrais commencer a savoir que ca existe )

Pour les ressources dans les DCU, ça m'étonnerait que Windows accepte d'ouvrir un DCU comme un module...

Ouaip ...


Bon sinon pour le moment je tente, non sans mal a cause d'un mal au crane a passer 15j a refflechir sur des problemes a la C.. (cf mes posts de ces 10 derniers jours ;p) de mettre en place un systeme base sur la generation de fichier Checksum MD5.
J'ai un log qui permet de generer un MD5Sum contenant une liste de fichier et leurs empreintes MD5 (et aussi accessoiremeent de les verifier ;p)
Apres je DL ce fichier, je teste, si different, alors je DL le fichier.
Apres avoir epuré la liste des fichiers local de ceux dont le teste a ete effectué, devrais me rester plus que ceux qui n'on plus de persistance sur le serveur ... donc mentionné comme obsolet et viré.

Si qqun a mieux .... Je prends ;p
(et le premier qui attends que j'ai fini mon expert pour em rofiter je lui fait bouffer !! *Joke* )

[Mac LAK]

Et a plus long terme . .faudra l'adapter a la mise a jours de notre logiciel qu'on vendra .... (mais le principe restera foncierement le meme !!)

Justement, c'est ça qui est bien en y collant un fichier (INI ou XML) compressé : tu le renommes en ".upd", par exemple, tu donnes juste l'URL de téléchargement ("http://www.maboite.com/updates" par défaut, mais pouvant éventuellement changer, notamment pour une adaptation client), et chaque logiciel sait quel est le nom de son fichier à télécharger... Après, le fichier d'update lui-même peut contenir une autre URL pour le téléchargement "lourd", par exemple un FTP... Qui vérifiera un login/mot de passe (d'après infos de licence) pour autoriser la MAJ... Ou n'importe quel canal de transmission pouvant être sécurisé d'après des infos de licence (histoire qu'en choppant un ".upd" au hasard, on ne récupère pas la version complète !)
Moi, je trouve ça sympa comme principe, pas toi ? ;-)

Oki je me pencherais la dessus .. mais bon j'ai pas trop d'interet a ca tant que ca ne touche pas la mise a jour d'application commerciale mais reste interne a la societee pour la mise a jours des outils de production.

D'où l'intérêt de gérer la compression dès le départ... Ainsi, tu n'auras pas à refondre ton appli lors de l'utilisation pour les softs de la boîte.

Moi aussi Finalement les fichiers Ini sont pas si mal que ca 0:-)

Bah, si nécessaire, tu peux "chaîner" tes sections entre elles via une clé spécifique "ChildrenXXX", "XXX" étant un numéro séquentiel histoire de pouvoir avoir plus d'un sous-répertoire... Si tu lis l'intégralité du .INI et que tu reconstruis ce chaînage, tu obtiens une structure genre TTreeView et ça, je pense que tu sauras très facilement le gérer.

Oki j'ai vue ca deja quelque part .... Ca me semble un peut lourd pour un systeme de mise a jour .. amoins que ca ne concerne de grosses applis.

En fait, ce serait plutôt pour les trucs possédant une horde de fichiers... Avec des blocs très courts (genre 1 ko), les déplacements de blocs seront gérés directement par le système de parité. Je t'encourage vivement à faire des essais (et à me donner les résultats, ça m'intéresse aussi !! )

Apres avoir epuré la liste des fichiers local de ceux dont le teste a ete effectué, devrais me rester plus que ceux qui n'on plus de persistance sur le serveur ... donc mentionné comme obsolet et viré.

Ben à peu de choses près, c'est le principe dont on est en train de parler, non ? Ou j'ai raté un chapitre ?

[Clorish]

Moi, je trouve ça sympa comme principe, pas toi ? Wink

En effet je me penche sur cette solution ;p

Ben à peu de choses près, c'est le principe dont on est en train de parler, non ? Ou j'ai raté un chapitre ?

Bha vi ... mais ca c'ets le but moi je cherche la maniere . Mon pb etait que du cote client je peut avoir des fichiers en trop a suprrimer et cot" serveur des ficheirs en trop a copier ....

Donc si je me base sur la liste serveur, je ne peut pas connaitre la liste des fichiers clients a supprimer ... et si je me base sur la liste cliente je ne peut pas connaitre les fichier a telecharger (nouveaux). et l'idee de passer par uen double liste a fusionner pour avoir la liste integralel des fichier me cassait les pieds .... et celle de me baser uniquement sur la liste des ficheirs serveur en supposant garder une trace de tous les fichiers supprimes me semblais pas assez fiable :/

Je vais peut etre me lancer sur une liste uniquement base sur les fichiers serveurs pour la copie des nouveaux fichiers (si ils n'existent pas en local) et la mise a jour des existant.
Pour les fichiers "obsolette" dans le cas de mes libs ca devrais ne pas gener .... et je les supprimerais avec un "Synchronize" que le developpeur lancera periodiquement quand il foudra faure le "menage".

En tout cas merci pour cette discussion tres constructive ... je pense qu'elle a un interet a etre copiee quelque part non ?