* Hirarchisierung der Klasse AccDevExc. Etwa sowas:

    exception -> AccException -> AccDevExc

  In [4, Seite 977] sind die C++-Standardausnahmen aufgeführt. 
  Daraus ergäbe sich womöglich eher

    exception -> runtime_error -> AccException -> AccDevExc

  Zu beachten ist aber, dass `AccDevExc' als CORBA-Exception
  implementiert ist, also in accdevexc.idl. Das C++-Mapping
  sieht dadurch so aus:

    class AccDevExc : public CORBA::UserException 

  Die Klasse AccDevExc erbt also CORBA::UserException und diese
  wiederum CORBA::Exception, also

    CORBA::Exception -> CORBA::UserException -> AccDevExc

  Ob und wie da weiter hirarchisiert werden kann, weiß ich nicht.
  Eigentlich geht nur noch

    CORBA::Exception -> CORBA::UserException -> AccException -> AccDevExc

  Worin unterscheiden sich die letzten beiden?

-> Ok!


* Es wird noch das lokale global-types.h benutzt, weil das zentrale
  das Alignment festlegt, z.B.: 

    typedef signed long SLong __attribute__ ((aligned(4)));

  Das sollte man mit "#ifndef"s machen.

-> Ok! Aber noch nicht mit derzeitiger GSW getestet.
   M68K-Crosscompiler muss "-D__m68k__" definieren.


* In den CORBA-unabhängigen Modulen überall AccDevExc durch 
  AccDevRetStatus ersetzen.

-> Ok! Auch in den USRs auf der Server-Seite.


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

-> Ok! Alarme sind zunächst mal auf Basis von UDP-Multicasts
   realisiert.


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

-> Ok! Mit Doxygen. Rahmen gibt's noch keine.


* Evtl. für AccData noch eine Methode erfinden, die statt einem
  UByte-Array (bzw. einem UByte-Vector) den entsprechenden String
  zurück liefert. Das wäre z.B. beim Lesen der Property VERSION
  ganz nützlich. Die Methode sollte aber nur auf Basis von UByte
  tun. Kommen andere Daten zurück, sollte es einen Fehler geben.

-> Ok, String gibt's.


* Evtl. für AccData noch eine Methode erfinden, die statt einem
  UByte-Array (bzw. einem UByte-Vector) den entsprechenden String
  zurück liefert. Das wäre z.B. beim Lesen der Property VERSION
  ganz nützlich. Die Methode sollte aber nur auf Basis von UByte
  tun. Kommen andere Daten zurück, sollte es einen Fehler geben.

-> Liegt nun auf SIS$ROOT:[SYSVME.DEVMAN]. Ist aber auch nicht
   so der ganz richtige Platz.


* Da nun (das CORBA-unabhängige) AccData auf Client- und Server-Seite
  benutzt wird, sollte man die `libdeviceaccess' in zwei Bibliotheken
  auftrennen:
  - libdeviceaccess:  enthält nur die auf Client-Seite notwendigen
                      Objekte.
  - libaccdata:       enthält alles, was man für AccData auf beiden
                      Seiten braucht.
  Die 'libaccdata' muss dann natürlich nativ für asl und cross für
  ppc gebaut werden. Im Moment sind die AccData-Sachen für ppc 
  in der 'libdevice' integriert.

  Was ist z.B. mit unserem NameService? Den könnte man evtl. auch 
  auf beiden Seiten brauchen. Falls ja, dann eine weitere Bibliothek 
  machen, oder mit in libaccdata rein und der einen allgemeineren 
  Namen geben?

  Zur Zeit gibt es weiterhin noch libequinf und libdevice auf der
  Server-Seite. Wollen wir die evtl. zusammenfassen? 

-> Ok, geregelt.


* Wegen der Klarheit sollte man den CORBA-spezifischen Namespace "DevError"
  besser in "CorbaError" oder "CorbaDevError" umbenennen.

-> Ok, ist auch im Namespace CorbaInterface.


* Das Sub-Projekt 'mk', das derzeit unter 'utivme' liegt, sollte
  besser nach 'utiasl' oder 'uti' umziehen. Produktionsmäßig 
  liegt es auf $DROOT/mk. Außerdem braucht das Projekt noch 
  ein 'Makefile' mit den üblichen Targets (release, ...), um es 
  vom Workspace auf das allgemeine Directory kopieren zu können.

-> Ok, erledigt.


* Alle Tools, die irgendwie Dateien auf Arbeits-Directories kopieren
  oder entsprechende Directories anlegen, wie z.B. releqms oder copyusrs, 
  sollen statt dem Copy-Befehl cp besser install benutzen. Damit kann 
  man explizit die umask der Zieldatei bestimmen und umgeht das Problem, 
  dass Dateien bzw. Directories nicht die notwendigen Permissions für
  die Gruppe haben.

  Bash-Scripts LH, ok
  Erzeugen der Logfiles (=...belcg04/2007-05-24.log=) steht aus.
  Frage: Wie geht das in Python? Mit os.chmod(file, umask).
 
-> Ok, alles erledigt.


* Für konnektierte Aufträge zweiten Zeitstempel einführen: Ausführungszeit des Auftrages.
  Wird bei Eventkonnektierung benötigt, um Daten konsistent zusammenzuführen.
  Bei Zeitkonnektierungen nicht so dringend, könnte auch dort mal hilfreich sein,
  schadet zumindest nix, und kostet wohl auch kaum was.
  * Eventkonnektierung: Zykluszeit des Events (von SE zu liefern)
  * Zeitkonnektierung: Ausführungszeit der USR (auf GµP)

-> Ok, für Eventkonnektierung erledigt. Zeitkonnektierung kommt erst mal nicht.