Eksisterende modulstøtte
Med modulstøtte menes her ikke det Python kaller moduler, men heller logiske pakker av egenskaper i Cerebrum. En modul består gjerne av:
- Databaseskjema
- Klasser og funksjoner som bruker databaseskjema, herunder mixins
- Konfigurasjon av modulen
Formålet med modulen er da å kunne lagre data som trengs i ulike systemer, men som likevel ikke trenger å være med i core.
Hva er galt?
Noen moduler er i dag for tett koblet. F.eks. kan ikke Cerebrum brukes uten enkelte moduler. Da bør disse kanskje vurderes flettet inn i core, ev. endre koden til ikke å avhenge av modulene. Andre moduler avhenger av hverandre, men det finnes ingen annen mulighet for å finne ut dette enn ved å prøve og feile.
I den andre enden er moduler løst sammenhengende. Med det menes at man manuelt må konfigurere opp
- databaseskjema (kjøre makedb.py),
- mixins (cereconf), og kanskje
- egen konfigurasjon av modulen
for å kunne kjøre Cerebrum med angitt modul.
Fremtiden
Vi ønsker et Cerebrum hvor brukeren angir hvilken funksjonalitet han trenger, så regner Cerebrum ut resten. Hvis jeg f.eks. trenger Exchange, så legges dette inn i Cerebrums konfigurasjon, og Cerebrum kan da
- finne ut hvilke andre moduler som trengs,
- finne ut hvilke SQL-filer som må installeres, og
- finne ut hvilke mixins som skal inn, og i hvilken rekkefølge.
Kanskje mere også. Modulen må kunne se at det trengs oppdatering av databaseskjema og utføre dette selv.
I tillegg må vi se på om det er mulig med en plugin-struktur. En modul vil i dag gjerne bestå av
- sql-fil under design,
- Python-moduler spredt rundt i treet,
- linje i versjonsjekken i makedb.py,
- scripts som bruker modulen, og
- konfigurasjonsmuligheter.
Det er lett å glemme f.eks. å oppdatere makedb.py når man lager ny modul, særlig når det ikke er noe som klager.