Deuxième cap: les sockets.

Maintenant qu’une base est prête il va falloir s’attaquer à la partie client/serveur du projet, ce qui -je l’avoue- ne sera pas de tout repos. Ecrire un library pour les sockets, définir un protocole de communication, l’implémenter, sécuriser le tout, faire des tests, etc.

Pour l’instant je vais commencer par écrire une library générique de gestion de sockets en attendant que j’écrive un protocole de communication. A moins que je n’opte pour de l’HTTP ou du FTP (qui ont chacun des avantages et des inconvénients).

En tout cas voici les besoins primaires identifiés pour le moment :

  • Récupérer la liste des packages
  • Télécharger un package

Je parle ici des besoins d’un client, l’administrateur doit être sur la machine en question pour effectuer les opération de gestion (pour le moment, hein, par la suite il est évident qu’une interface à distance sera dispo pour les administrateurs).

Voici donc les grandes tâches à réaliser avant commencer à distribuer binforge sous forme binaire :

  1. Interface client/serveur basique pour récupérer les packages.
  2. Implémenter un repository intermédiaire (récupère les packages pour les redistribuer).
  3. Mettre en place un système de gestion de sources (fichier contenant la liste des serveurs auxquels se connecter pour récupérer des packages, à la sources.list).
  4. Développer une interface administrateur à distance.

Au travail ! :D

PS : Je vais bientôt commencer à publier des binaires, juste pour les tests. Leur usage doit rester exclusivement dans une optique de test/débug, car la compatibilité entre les versions 0.x.x n’est pas assurée pour l’instant.

Leave a Reply