• Überhaupt noch mal über public, protected, private nachdenken.

• Ebenso über const (oder nicht) nachdenken.

• Alarme womöglich mit dem CORBA Events Service (oder dem CORBA Notification Service?) realisieren. Siehe dazu " Pure CORBA" , Kapitel 12, besonders (den ersten Absatz in) "CORBA Event Service Patterns".

• Was ist eigentlich mit Timeouts? Kann/muss ich implementieren, dass z.B. ein Lesezugriff nach der Timeout-Zeit mit Fehler beendet wird? Für die USRs tun das die Funktionen readCommand() und writeCommand(), falls ein EQM nicht antwortet. Wer tut das für "Userface", wenn eine USR nicht antwortet?

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);
    };"
  ----------------------------------------------------------------------

• Alle Methoden einer Klasse sollten mit einer Info versehen werden, ob sie eine Exception werfen oder nicht. Mit einer leeren Throw-Anweisung int f(float); throw(); kann man sagen, dass f() keine Exception wirft.

• Wie machen wir die Incode Documentation? Mit Doxygen? Wieder einen (oder mehrere) Rahmen für Klassen, USRs, etc. entwickeln?

• In vmedevice.hh wird devInfoP() ungeprüft (= NULL) zurückgegeben. Das knallt, wenn der Pointer NULL ist. Da muss man was tun! Wo ist das noch so?

• Es fehlt noch der eine oder andere Namespace in einigen Dateien!

• Gedanken zu konnektierten Aufträgen:

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?

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.

• AccData: Für VMS die Konvertierungen Float32 <-> G_FLOATING und Float64 <-> H_FLOATING (???) einbauen.

• Die Module des Client-Interfaces (callback*.*, device*.*, nameservice*.*) sollten AccExceptions werfen statt AccDevExceptions. Oder?

• Was machen wir mit den Errors "42", "4711", ... in den Exceptions "=AccDevException(42, ...)="? Da ist wohl eine eigene Facility nötig. Und die Messages müssen weiterhin auf VMS generiert werden.

• Die ganzen Objekte aus den Dateien *-corba.o (noch mehr?) in eine Bibliothek verfrachten. Vielleicht in eine Shared Lib? Wohin mit den Header-Files, die ein Anwender nicht sehen soll?

• Sollten die Methoden requestRead(), requestWrite() und requestCall() nicht auch eine ConnId zurück liefern wie die entsprechenden connect-Methoden? Und ist es möglich, dass man auch einen Request disconnecten möchte? Ein Request ist im Prinzip ein Connect, der aber nur einmal läuft. Es weiß aber niemand, wann und ob. Von daher wäre ein Disconnect sinnig.