OpenPHPNuke - das Open Source CMS

Autor

stefan

Datum

07.12.2006 18:03

Beiträge:

Freespacer schrieb am 07.12.2006 um 17:15:59 Uhr folgendes:

Ist alles schön und gut. Aber vergisst du nicht etwas entscheidendes? Wenn Modul X von Modul Y die Version 1.1 benötigt. Wie du so schön sagst, dass Modul Y hat seine Version aber 2.0 erhalten. Dann sagt es doch im Prinzip aus. Das Modul X bisher mit Modul Y Vers. 1.1 einwandfrei läuft, aber Modul Y mit Version 2.0 nicht angepasst wurde (Braucht nur ein Funktionsname im Modul Y sich ändern). Daher auch Hardcoded wegen der Kompatibilität unter den Modulen, weil der Entwickler von X weiß, dass sein Modul X mit Modul Y Vers. 1.1 läuft.

nein nicht zwingend

das problem ist klar und muss gelöst werden, dazu gibt es 2 möglichkeiten. mit allen 3 möglichkeiten wir in opn "gespielt"

1) Versions Controll System; jedes Moul weiss von wann bis wann es arbeitet besser das zu benutzende Modul sagt wann es denn nicht mehr geht. Das kann man durch interne stukturen und eine strikte Versionsvergabe erreichen.

2) feste klassen einsprünge und erreignis punkte sowie registrierte funktionen

ich hoffe die stichworte reichen sonst muss ich es ausführlicher machen.

Freespacer schrieb am 07.12.2006 um 17:15:59 Uhr folgendes:

Die Datenbank soll das Modul X, dass obsolet ist, dass andere Modul Y auch ausschalten? Da muss man wirklich Versionsprüfung betreiben, dann können unter umständen auch alte Modul laufen, wenn diese untereinander gebrauchen werden, aber nicht von einem Modul, der das neuste vom neusten Modul benötigt.

sicher wobei das nur selten auftretten kann da sofern 2) von oben zu 100% umgesetzt ist. denn dann ist jede höhere version zu der alten kompatibel

Freespacer schrieb am 07.12.2006 um 17:15:59 Uhr folgendes:

Hä? Eine zentrale Datenbank, die nicht zentral ist?! Äh.... Meinst du etwa eine Peer2Peer-Datenbank???

nein; DNS kennst du? ist auch ne "Art" Datenbank. Its die Zentral? Ja; Ist sie zwingend! Zentral? Nein