• Remote genmsg.com auf VMS von Linux aus aufrufen mit vorherigem Kopieren eines *.msg-Files von Linux nach VMS.

• Generell sollte noch mal über Timeouts im Zusammenhang mit CORBA, Device Access, Linux-Userface usw. nachgedacht werden.

  Server-seitige Timeouts für Callbacks sind, glaube ich, nicht notwendig, weil die (CORBA-) Callbacks nicht auf ein Acknowledge warten.

  Wie kann man Timeouts für Aufträge (via CORBA) setzen? Siehe u.a. http://omniorb.sourceforge.net/omni41/omniORB/ und den Hinweis zu Timeouts in [3]:

    ----------------------------------------------------------------------
    omniORB can associate a timeout with a call, meaning that 
    if the call takes too long a TRANSIENT exception is thrown. 
    Timeouts can be set for the whole process, for a specific thread, 
    or for a specific object reference. Timeouts are set using 
    this API:

      namespace omniOrRB {
        void setClientCallTimeout(CORBA::ULong millisecs);
        void setClientCallTimeout(CORBA::Object_ptr obj, CORBA::ULong millisecs);
        void setClientThreadCallTimeout(CORBA::ULong millisecs);
      };"
    ----------------------------------------------------------------------

• Die DB-Dateien für X86-Devices brauchen keine IFK-Adresse zu enthalten. Möglicherweise braucht man für HITRAP eher eine IP-Adresse. Soll mit der XML-DB bedacht werden.

• Eventkonnektierung verbessern, sodass auch Properties von nicht SE-gestützten Geräten eventkonnektiert werden können.

• Es gibt eine Grenze für die Anzahl von Konnektierungen auf einer Maschine. Die liegt auf asl-Rechnern bei < 300, auf PPC-Rechnern bei mehr etwa 700. Klaus hat geforscht und meint, dass das wohl eher eine Linux- denn eine omniORB- Begrenzung ist.
  Es sollen Versuche mit "Thread Pools" gemacht werden.

• Exceptions: Oft können nur AccDevExceptions weitergereicht werden. Tritt in diesem Zusammenhang z.B. eine CORBA-Exception auf, wird sie in eine AccDevException umgewandelt und weitergereicht. An dieser Stelle könnte die originale (CORBA-) Exception ins Logfile geschrieben werden, oder vielleicht beide Exceptions, um später den Zusammenhang besser herstellen zu können.

• Incode-Docu ist zwar am wachsen, aber zur Zeit nach Projekten sortiert. Das macht nicht so recht Sinn, weil man zum Teil erraten muss, wo eine Klasse steckt, die man sich angucken möchte.

  Nachdenken, ob man eine Docu generiert, die alles enthält, oder ob man nur in Client, Server und Allgemein trennt.

  Die Docus der Gerätemodelle sollten natürlich getrennt bleiben.

• Unser Nameservice muss eine Wildcard-Suche nach Nomenklaturen, z.B. K*CG*, erlauben. Das wird u.a. von NODAL LSTDM benötigt.

  In diesem Zusammenhang sollten wir uns auch einen vernünftigen "context name" überlegen. Der aktuelle ist immer noch test.my_context.

• Alle Tools sollen mit einem Header versehen werden, der kurz erklärt, was das Tool tut, wie es aufzurufen ist, welche Besonderheiten es gibt und wer Änderungen daran gemacht hat. Auch ist es ziemlich sinnvoll, den Code selbst mit ein paar Kommentaren zu versehen!

• Sollte man noch mal allgemein über eine konsistente und deskriptive Benamsung von Klassen, Methoden usw. nachdenken?
  • Sollte man z.B. immer alles ausschreiben? Also setDeviceConstants() statt setDevContants().
  • Sind die Klassennamen Device, AccDevice, GenericDeviceInterface usw. die passenden im Hinblick auf eine Vereinheitlichung von Client- und Server-Seite?

• Neue Konnektierungsart "on change" oder "Monitor" erfinden. Daten immer dann liefern, wenn neue Daten vorliegen
  • Slave-Daten: Mit jedem Ablauf eines virtuellen Beschleunigers
    • SE muss sagen, wann neue Daten da sind
  • Master-Daten: Periodisch
    • Refreshrate sollte gleich sein für alle aufgesetzten Konnektierungen
    • Refreshrate fest eingestellt (z.B. 1 s)?
    • Konnektierung: Nur Untersetzung dieser festen Refreshrate möglich?
  • Konnnektierung muss sich merken, welche Daten schon verschickt sind (Index im Ringpuffer), und so lange Daten schicken, bis sie bei den neuesten angekommen ist
  • Daten nur dann liefern, wenn einstellbare Toleranzschwelle überschritten wird
    • Toleranzbandüberwachung
    • Toleranzschwelle = = 0: Daten aus allen abgelaufenen Zyklen (eines virtuellem Beschleunigers), d.h. immer dann, wenn es neue gibt. Realisiert Stream-Funktionalität.

• Zeit-Konnektierung (um soundsoviel Uhr) implementieren?

• Da ich gerade in der c't 5/07 auf Seite 49 lese, dass der GCC-4.0-Zweig endet, hier noch mal die Frage, wann wir auf Linux 2.6 und GCC 4.x umsteigen wollen? Zur Zeit haben wir Linux 2.4 und GCC 3.2.3.

• Bei Ansicht des idl-files, was ich so gefunden habe, ist mir aufgefallen, dass die Angabe der Konnektierung noch recht straightforward realisiert ist. Muss sicherlich noch einmal überdacht werden. Dazu, zum Merken:

  Ist etwas sinnvoll, um nachzusehen, ob die Konnektierung noch besteht? Man will sich vielleicht nicht ganz darauf verlassen, dass CORBA schon Bescheid sagt, wenn etwas schiefgeht. Sicherlich möchte man ja auch mal das Eine oder Andere über die Konnektierung wissen:

  • wann aufgesetzt?
  • was wurde eigentlich mal aufgesetzt (periodisch oder event)?
  • wie oft ist sie schon gelaufen?

• Siehe Punkt weiter oben Wir sollten ferner eine Erweiterung der existierenden Konnektierungsarten anpeilen: "Monitor". Was mir vorschwebt: Eine Antwort nur, wenn sich ein Wert ändert (bzw. ein Toleranzband verlässt). So was muss derzeit kunstvoll hingetrickst werden. Auch wenn wir sowas nicht gleich einbauen, sollte die Schnittstelle für die Konnektierungen so flexibel sein, dass das noch reinpasst. Dazu sollte man vielleicht einen Referenzwert und sicherlich ein Toleranzband angeben können.

• Dringende Empfehlung: Wenn wir nicht ganz sicher sagen können, dass in der IDL-Schnittstelle voraussichtlich immer ein Einzelwert ausgetauscht wird, sollten wir vorsichtshalber lieber gleich eine struct nehmen, die zunächst nur diesen Einzelwert einhält. Dann kann man später relativ problemlos zusätzliche Elemente hinzufügen, ohne den Anwender-Code für den Zugriff auf die bereits existierenden ändern zu müssen. Man muss 'nur' alles neu übersetzen, da sich ja das Datenlayout ändert. Betrifft z.B. ConnId und Property. Potentiell könnte sogar die Angabe des virtuellen Beschleunigers betroffen sein - allerdings würde es sicherlich ganz massive Änderungen erfordern, wenn dafür eine simple Nummer mal nicht mehr ausreichend ist.

• Collisions have to be avoided with actually performing device access, e.g. Pointers used in execution of a device access should not be modified during the device access. Appropriate synchronization should be done.

• DeviceManager for Windows: Zentrales Directory fuer Lockfile?

• Tools zum Management, wenn mehrere Komponenten betrofen sind
  • Beispiele:
    • Nameserver komplett neu aufgesetzt, alle devman müssen für alle Geräte neue Einträge anmelden
    • entsprechend: es ist nicht sicher, ob alle Geräte ordentlich beim nameserver angemeldet sind - alle devmans auffordern, vorsichtshalber alle Geräte neu anzumelden
    • neuer devman (neue Version) verfügbar: diesen überall neu installieren (neu starten)
  • Aufgabe: sollte gehen, ohne jeden devman einzeln anfassen zu müssen
  • Ideen zur Implementation:
    • scripte, die auf mehreren (VME-)Rechnern remote ausgeführt werden
    • Broadcast-Kommandos ("an alle devman"), vorzugsweise über einen Weg, der weitgehend unabhängig vom Kontrollsystem-Umfeld ist (etwa unabhängig von einem speziellen Nameserver). Denkbar: über eigenen Multicast-Kanal.

• Idee: Pruefsumme fuer Dateien einfuehren, die oft geaendert werden (z.B. accessdata.txt), haeufiger uebertragen werden oder nicht von jedem editierbar sein sollen.

• Idee fuer devman: Option -h/--help einbauen umd die moeglichen Parameter anzuzeigen