search

mdl29 / panobus

Panobus
GNU Lesser General Public License v3.0
2 stars 1 forks source link

S'étendre à d'autres villes que Brest #7

Open philae-ael opened 8 years ago

philae-ael commented 8 years ago

Reprise des message de #6 Benvi :

+1 et pourquoi pas en gros faudrait se baser sur "l'interface" de Adafruit_NeoPixel (qui n'est pas >énorme : https://github.com/jgarff/rpi_ws281x/blob/master/python/neopixel.py ). Mais c'est à mon sens trop complexe pour le relier à des tests unitaires ... sauf si de l'autre coté tu as aussi des jeux de données de test bibus en entrée :) Donc se subtituer à l'API Bibus ce qui serait intéressant ça ouvrirait aussi la porte à d'autres API >(La Star à Rennes ...) ça nécessite de revoir le code et réfléchir à quelque chose d'ultra modulable >(regarder d'autres API).

Moi :

J'y avais pensé, mais j'avais pensé à juste créer un wrapper avec une api «de base» (d'après ce que l'on utilise) qui sera redéfinie pour chaque api que l'on ajoute le problème c'est comment passer d'une api à l'autre sans avoir à modifier le code (j'avais pensé à un __import__(api name) mais je trouve ça moche)

Tristanplouz:

Pour développer le projet il faudrait qu'il soit construit en 3 partie:

  • Une partie API avec la gestion des API de Bibus, de la STAR, de KSMA,etc
  • Une partie qui traite les infos indépendantes des API et de l'affichage
  • Une partie qui gère l'affichage sur les LEDs ou sur un écran

Avec cette structure je pense que le projet sera entièrement modulable et ensuite plus simple à modifier

Benvii commented 8 years ago

@naegi tu auras dans tous les cas besoin de faire un import :) après tu peux utiliser un patron de conception genre Adapter, tu as une implem pour chaque API qui est potentiellement complètement différente tu défini une interface et tu adapte chaque implem pour chaque API.

philae-ael commented 8 years ago

C'est ce à quoi je pensais en parlant de créer un wrapper autour des api (faut vraiment que j'apprenne le nom de patrons de conception)