Ich habe jetzt auch dafür gevotet.
Denn ich fange jetzt an Logiken zu schreiben und natürlich ist nicht jede GA, die ich spannend finde verknüpft.
Also Workaround anwenden (
app.php/kb/viewarticle?a=94).
Währenddessen schreibt und liest die CometVisu ohne Probleme fleißig auf dem Bus und mir ist erneut nicht klar, welche Vorteile dieses Konzept mit der ETS-App für mich haben soll, wenn ich über mehr Nachteile stolpere als ich bisher Vorteile für mich ausmachen würde.
Ich bin daher sogar für einen "radikaleren" Ansatz:
Denke den letzten Schritt ''mit der ETS synchronisieren" komplett anders.
Grundthese:
Wenn du den 4ten Schritt "mit ETS synchronisieren Schritt" weglässt, haben 80% der Nutzer keinen Nachteil. Der Timberwolf liest und schreibt auf den Bus, wie er lustig ist (sogar zertifiziert). Und für Kunden sind Schritt 1-3 total intuitiv und super elegant.
Wer sind die letzten 20%, denen das nicht reicht?
Alle diejenigen, die etwas komplexere Topologie haben und wo die ETS die Applikation/Gruppenadressenzuordnung braucht, um die Linienkoppler korrekt zu programmieren.
Diese Nutzer würden nun normalerweise ein Dummy-Objekt anlegen und dabei viel falsch machen können, bzw. hohen Aufwand damit haben.
Und jetzt kommts:
Objekt 1-8999 des Timberwolf werden nie in der ETS angelegt (und auch nicht hin- und hersynchronisiert mit all den potenziellen Problemen).
Dafür gibt es Objekt 9000-9020 mit klassischer "Dummy" Funktionalität, die der Timberwolf zwar besitzt aber eigentlich komplett ignoriert. Zzgl. einen Importer, der alle GAs passend zu ihrem Typ auf die paar Dummy-Objekt packt.
Die ETS ist dann glücklich. In der Folge sind die Linienkoppler auch glücklich. Der Timberwolf Nutzer sind glücklich. Und deine Entwickler auch, denn du bist den Großteil der sich gegenseitig beeinflussenden Synchronisationsprobleme los.
