Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

[ragnar]

So, jetzt mal einige Kommentare zur aktuellen Diskussion der
Diensteschicht (bzw. alle Schichten drüber)

Ich habe bislang geplant für den Datentausch wie gewöhnlich SOAP zu
verwenden und weitere Systemteile sofern notwendig mit CORBA zu
verschabbeln. Ist S²MIRS als etwas ähnliches angedacht oder ist das
Layer zu tief?

Wenn ich smirs richtig verstanden habe, dann könntest du SOAP
als 'Transfer' schicken. Problem: die Variablen in smirs sind
auf derselben Schicht wie 'Transfer'. Die kannst du also mit
XML nicht so erfassen. IMHO werden in smirs weder Bedeutung
noch Typ der Variablen festgelegt. Die Definition komplexer
Strukturen unter einem Namen ist jedoch möglich.

PS: An die Doktorarbeitschreibsler ...etwas pragmatischer wäre net
schlecht, denn ich bin Informatiker und kein Theologe. Und der glaube
an ein System das multi private, public semiperstent, private persistent,
private kill... rollback public .. watch hangoff .. deadloop ... watch
external, handeln kann ist bei mir und zudem Naturwissenschaftlich schon
widerlegt.

Allein mit diesem Satz kann ich jedes Boolshit Bingo mit
Pseudo-Informatik-Buzzwords gewinnen. Wenn du genau aufgepasst hättest,
dann wüsstest du, daß ich nur über die Sicherung der unteren Ebene
geschrieben habe. Mag sein, das dich das als Anwendungsentwickler nicht
interessiert. Mich als Hardwarenahen Entwickler interessiert es durchaus.
Genaugenommen steht es durchaus auf meiner Wunschliste (allerdings recht
weit hinten) und deshalb werde ich auch drüber nachdenken. Nur weils
dich nicht interessiert oder nicht betrifft, brauchst du nicht gleich
diskreditierende Kommentare dazu schreiben.

Ragnar hat weiter vorne ein Schichtenmodell vorgeschlagen.
Schicht 1 Übertragung
Schicht 2 Routing
Schicht 3 Verbindung
Schicht 4 Dienste
Ragnar z.B.möchte bis Schicht 3 bei der Entwicklung helfen.

Nach diesem Modell sind
Deine geplante GUI Schicht 4 .
Deine angeregte Festlegung von Werten Schicht 4.

Zur Zeit liegt der Fokus auf den Schichten 1,2 und 3 um der Schicht 4
die Plattform-Unabhängigkeit zu schenken. Bevor das nicht steht kann
man der Schicht 4 nicht sagen was sie vom Datenverkehr erwarten darf
und was sie erfüllen muss.

Ja Marvin, genau so habe ichs gemeint. SOAP auf Schicht 4 wäre durchaus
möglich. Aber in einem Punkt muss ich dich korrigieren. Man kann jetzt
durchaus schon über Dienste reden. Es ist sogar sinnvoll, das jetzt schon
zu tun, da die Dienste u.U. gewisse Ansprüche an die Schicht 3 haben.
Je früher man das erkennt und integriert, desto besser.

BTW: Über Schicht 4 habe ich auch so meine Vorstellungen, weis aber noch
nicht, ob die mit den euren Zusammenpassen.

Ok, das mit den Layern klingt irgendwie wie Standard TCP/IP ...
Gar nicht so übel wenn man das wirklich in einen Contoller packen könnte.

Ja, da ist viel bei IP abgeschaut und zwar nicht zufällig. Wenn IP auf
einem uC laufen würde, dann würde ich die eigentliche Software auch direkt
auf IP aufsetzen. Leider ist der Overhead dabei recht groß, weshalb ich
das ganze einfach runterbrechen will.



@UlrichC
Darf ich dich mal etwas zu deinen Posts fragen. Wenn ich das richtig
verstanden habe willst du eine allgemeine Roboter GUI programmieren.
Wie genau stellst du dir das vor ? Was soll die GUI alles können ?
Wie soll sie beliebige Roboterdaten allgemein darstellen können ?

Beispiel: Ich habe in den letzten Posts häufig von Variablen, Typisierung
und Einheiten(naja, auch nur Typisierung) gelesen. Wie soll das z.B.
ganz konkret aussehen ?

Macht doch mal bitte noch mehr Beispiele, mich würde interessieren
wie ihr euch eine GUI konkret vorstellt ...

Wenn ich das weiter richtig verstehe, soll es einen 'Application Server'
geben, der an das Robotersystem angebunden ist. Jetzt wirds etwas unklar.
Wenn du im folgenden von Drivern und Modulen und Softwarearchitektur redest,
dann nehme ich an, all dies bezieht sich auf den Application Server. Auch
nehme ich an, das du bei Schnittstellen immer die Schnittstellen des
Application Servers auf Schicht 4 meinst. Mit den uCs soll per SOAP
kommuniziert werden. Nicht klar ist mir, was für Standards da erzwungen
werden sollen.

Mal ein konkretes Beispiel ob ich deinen Applikationserver richtig
verstanden habe. Der Applikationserver lädt zur Laufzeit (vmtl. zum
Start) ihn vorher unbekannte Module. Diese Module können z.B.
Hardwaretreiber sein, interne Hilfsmodule für Datenaggregation
und -aufbereitung sowie Module die die Daten schliesslich graphisch
auf den Bildschirm bringen.

Dir geht es also nur um die interne Softwarearchitektur der GUI, richtig ?
Im Prinzip finde ich die Architektur der GUI so gut, allerdings auch
ganz schön allgemein. Andererseits sollte der Overhead durch XML, SOAP oder
CORBA auf dem Rechner mit der GUI kein Problem sein ...

Also im Grunde ein vorgefertigtes System .. das arbeit abnimmt und freiräume lässt.
In einer Hochsprache... mit Treibern zu den Controllern ... netten GUIs
Eine Art DEV Studio/Plattform/BDE für Roboter.

Dem würde ich jetzt voll zustimmen, allerdings ist das auch voll
unkonkret und schon fast Marketing-Gefasel


Noch zwei Dinge bevor für heute Schluss ist:

1.) Bisher haben wir noch (fast) gar nicht über die Schicht 4 auf den
uCs gesprochen. IMHO ist diese aber noch viel wichtiger als die
interne Struktur der GUI. Welche (allgemeinen) Dienste könnten
hier angeboten werden ?

2.) Vergesst bitte nicht, das ein Roboter aus wesentlich mehr als ein
paar Variablen besteht. Das ganze ist in erster Linie ein Nachrichtensystem,
kein synchronisierter Variablenpool. Ich beabsichtige das ganze auch
innerhalb der logischen Module meines Roboters zu verwenden. Ich will
Ereignisse abstrahieren und darauf reagieren. Variablenanzeige ist für
mich nur ein klitzekleiner Teilbereich.

ciao,
Georg