@Johannes:Zitat von Johannes
Genau darauf will ich ja hinaus. Hier liegt der Hund begraben. Das
Kommunikationmedium der MCs ist nicht losgelöst von den Nachrichten,
die darüber übertragen werden. Deshalb kann ich nicht einfach ein
neues Kommunikationsmedium einführen.
Selbst wenn ich jetzt eine MC schreibe, die das MC-Protokoll intern
auf RS232 ummodelt funktioniert dieser Proxy nur dann, wenn er alle
Funktionen einer MC implementiert und weiterleitet. Ändert sich also
irgendwas an der MC, muss ich meinen Proxy entsprechend ändern. Das
ist keine schöne Softwarearchitektur.
Unterm Strich sind die MCs damit praktisch auf Rechner mit IP festgelegt
und das ist für meine Ziele bei weitem nicht ausreichend.
Das Problem bei smirs ist aber IMHO auch, dass smirs sich eigentlich
auf die Dienste-Ebene beschränkt, wobei einer der beiden Dienste die
Übertragung von Nachrichten ist. Ich muss mich aber fragen: welchen
Nutzen habe ich von diesem Dienst, wenn alle Module sowieso IP sprechen ?
Warum kommunizieren meine Module dann nicht direkt miteinander, sondern
benutze das relativ aufwändige TRANSFER-System smirs ? Ich stimme zu
das es notwendig ist Dienste zu definieren. Ich stimme auch zu das
es notwendig ist ein 'abstraktes' Kommunikation/Adresssystem zu definieren
(Wie bei smirs über die Adressierung bei Transfer mit 'MC->Modulname').
Nur wenn schon dann sollte man es konsequent machen und die beiden
grundverschiedenen Dinge 'Kommunikationsinfrastruktur' und
'Variablensynchronisation' voneinander trennen. Wenn man dabei
die Variablensynchronisation als Schicht auf der Kommunikation
aufbaut, dann bekommt man nämlich ganz automatisch unabhängige,
modulare und flexible software.
ciao,
Georg
PS: Bitte sieh das ganze als konstruktive Kritik. Ich werde gerne jeden
Punkt noch weiter aufdröseln wenns sein muß. Nur leider sieht es für
mich im Moment nicht so aus, das smirs annähernd das erfüllt, was ich
für notwendig halte.
Zitieren
Lesezeichen