* Sollen die Parameter bei connect() so bleiben? Oder besser so

  ------------------------------------------------------------------------
  ConnIdType connect(in Property prop, in long vrtAcc, in AccData rcvPara, 
               in Connection con, in Callback cb)
    raises(DevError::AccDevExc);
  ------------------------------------------------------------------------
  mit eingeschränktem Parameter `Connection'? Das wäre zumindest vom Aussehen 
  her konsistenter mit den anderen asynchronen Methoden.<p>

  -> Ok, konsistent.
 

* Die Ausführung des readRequest() muss *auch* in einem eigenen Thread passieren, 
  sonst kommt readRequest erst zurück, wenn readResponse() beendet ist - was auch 
  leicht zu einem Distributed Deadlock führen kann.

  -> Ok!


* Zur Zeit (29.Okt.04) ist "no quit" möglich bei writeRequest(),
  callRequest(), writeConnect() und callConnect(). Ist das ok,
  besonders bei den beiden "Connect"s?

-> Das ist ok!


* Zugriffe wie data.f(), data.ul() usw. auf Elemente von AccData
  machen *keine* Plausibilitätsprüfung. Man kann also z.B. auf 
  ein Float-Element auch mit data.ul() zugreifen, ohne dass ein
  Fehler oder eine Exception generiert wird. 

-> Ok! DeviceAccess::AccData prüft.


* Kann man unsere Anwendungen so von CORBA trennen, dass es
  relativ einfach möglich ist, CORBA gegen eine andere Art der
  Kommunikation verteilter Objekte auszutauschen, also ohne dass 
  viel Arbeit in die Anpassung der Anwendungen notwendig ist?

-> Ok!


* Warum stürzt der Client ab, bzw. warum bekommt er eine 
  CORBA-Exception, wenn es eine aufgerufene Property nicht
  gibt? In diesem Fall sollte eine AccDevException auftreten,
  die besagt, dass es die Property nicht gibt.

-> Ok! War ein Client-Problem.


* Möglicherweise sollte man in den AccData::setxxx()-Vector-Methoden
  die anderen möglichen Vectoren initialisieren. Also: Bisher war
  "AccData d" ein ULong-Vector. Jetzt sage ich "d.setswv(...)". Dann
  wird's ein SWord-Vector. Damit sollte der ULong-Vector gelöscht
  werden: "_ulv.clear()".

-> Ok! Es wird zuerst init() aufgerufen.


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

-> Ok, erledigt.


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

-> Nein, nicht einbauen.


* 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.

-> Ok, ODA$MSG.MSG auf VMS unter SIS$ROOT:[SYSVME.DEVMAN]


* 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?

-> Ok, libcorbaifc.so und Design Patterns.


* 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.

-> Ok, ID wird geliefert.


* Reicht als ConnId ein einfaches ULong? Wenn ich es richtig sehe, wird
  die ConnId dem Callback-Aufruf mitgegeben, wenn der Auftrag ausgeführt
  wird. Da die ConnId nur innerhalb eines Gerätes eindeutig sein kann,
  sollte zusätzlich noch z.B. der Gerätenahme mitgegeben werden.
  Also z.B. ein struct nehmen, das ConnId und Nomenklatur enthält.
  Dann kann man dasselbe Callback-Objekt für mehrere Konnektierungen
  verwenden und die Antworten trotzdem eindeutig zuordnen.
  Kann die Anwender-SW vereinfachen.
  Möglicherweise für Userface nötig: Nämlich dann, wenn jedes Callback-
  Objekt ein eigener Subbprozess erforderlich sein sollte.
  Beim Aufsetzen eines konnektierten Auftrages reicht natürlich die
  ConnId aus, da dann ja die Nomenklatur bekannt ist.

-> Ok, ID ist eine Structure (Klasse).


* Den Call-Back Aufrufen mitgeben, um die wievielte Ausführung eines
  konnektierten Auftrages es sich handelt (das zu ermitteln ist natürlich
  die Sache des Servers).
  Dann hat man deine Schwierigkeiten, die Antworten in die richtige
  Reihenfolge zu bringen (wenn das mal erforderlich ist). Und:
  Da durchaus jeder Aufruf eines callbacks in einem eigenen Thread erfolgen
  kann (wenn nicht anders gesagt, organisiert das der ORB selber),
  hat man keine Garantie, dass sie schön der Reihe nach abgearbeitet werden.
  Wenn der ORB heftig beschäftigt ist und die callback-Aufrufe schnell
  aufeinander folgen, könnte dann schon mal was durcheinander geraten.

-> Ok!


* Zusätzlicher System-Zeitstempel bei Konnektierungen (UK, 9. Mai 07)
  * Bedeutung: Ausführungszeit einer Konnektierung.
    Die Zeit, zu der die konnektierte USR aufgerufen wird
  * Bei Eventkonnektierung: Timestamp des Zyklus, in dem das auslösende Event
    empfangen wurde. Muss von der SE zum GµP durchgereicht werden.
  * Bei Zeitkonnektierung: Die jeweilige Systemzeit auf dem GµP.
  * Zeitstempel wird von den übergreifenden (systemweiten) Teilen
    der Device-Objekte verwaltet / zugefügt und muss in der Client-Schnittstelle
    auslesbar sein.
  * Zielsetzung: Zeitstempel soll dazu dienen, bei Eventkonnektierungen
    Daten verschiedenener Geräte synchronisieren zu können. Ansonsten:
    Erlaubt, bei jeder Konnektierung einen Zeitstempel zur Verfügung zu haben,
    auch wenn die Gerätesoftware keinen versorgt hat
    (insbesondere bei Master-Properties).

-> Ok, Eventkonnektierung erledigt, Zeitkonnektierung erst mal nicht.