Release 6

Zeitrahmen: bis 31. Oktober 2007.

Beim Implementieren, sei es die Neuerstellung oder die Erweiterung einer Datei, auf jeden Fall die Merkliste und eventuell auch die Windows-Merkliste beachten!

Access Rights und Nameservice

• Use Cases sollen noch verfeinert werden. Der Fluss und die Verarbeitung des Access Patterns ist noch nicht klar.
• Server auf Basis von xinetd implementieren.
• Client-API durch Erweiterung des bestehenden Interfaces (Projekt nameservice)
• Der Nameservice muss eine Wildcard-Suche nach Nomenklaturen, z.B. K*CG*, erlauben.
• Nicht mehr vorhandene Geräte-Objekte sollen aus dem Nameservice ausgetragen werden, sonst hat man ziemlich viele Leichen mit der Zeit.

Property-Beschreibung mit XML und Code-Generierung

• Erste Vollständigkeitstests mit Gerätemodell DSME.
• Danach soll SWPZ umgestellt werden, da diese Software auch komplett (mit SE/EQMs) getestet werden kann.
• Es soll eine Einführung für Anwender geben, evtl. auch ein kleines Handbuch.

Subscription Service

• Beta-Version, zeigen der Machbarkeit
• 1. Release mit klarerem Code, besserer Objektorientierung

MBox und Gerätemodell DSME

• Offene Punkte klären
• Vollständigkeitstest mit Gerätemodell DSME
• Cosylab Treiber-Upgrade
• HW/SW-Integration

Userface, Nodal, ...

• ULong/SLong-Konversion
• Methode Callback::exit() implementieren
• Methode waitResponse() implementieren
• quit/noquit testen
• Perspektivisch soll es mehrere Userface-Server als nur den einen auf asl710 geben.

Diverses

• Persistent IORs
  • Endpoint für Persistent IORs implementieren
  • Beim ORB-internen "Reconnect" an persistente IORs können verschiedene Fehler auftreten, die an die Anwendung durchgereicht und von dieser ähnlich wie Timeout-Fehler behandelt werden müssen. Das muss mit AP abgesprochen werden.

• Anleitung "Devman bauen" anpassen/erweitern

• Automatisches Nightly Build inklusive SVN-Fetches implementieren

• Devman
  • Verhindern, dass mehrere VmeDevice-Bibliotheken unterschiedlicher Version unter einem Devman laufen.
  • An wenigen Stellen und eher auf der Server-Seite müssen noch aussagefähigere Fehlermeldungen ausgegeben werden. Im Beispiel weiß man z.B. nicht, was denn nun schief ging:

            Creating device LH1MU2
            failed

• ETH-Knotennummer im DPR der SE ersetzen durch die letzten 2 Stellen der IP-Adresse

• Manche Quellen sind ziemlich knapp dokumentiert (mit Doxygen), z.B. device.hh. Das sollte doch etwas ausführlicher, genauer geschehen, etwa mit dem Ansatz, was muss ein unbedarfter Leser wissen, wenn er dieses Interface/Modul/Paket nutzen will.

Später

• Für spätere Releases nachgucken in Allgemein: Zu tun, Client-Seite: Zu tun, Server-Seite: Zu tun und USRs: Zu tun.

• Userface-Server unter Linux (asl) mit Hilfe der Raphael-Userfaces realisieren. Die Entscheidung, ob wir das so tun wollen steht noch aus, liegt aber nahe.

---

Erledigt

• ECM-Anpassungen für Subscription Service
  • ok! PKain

• Absturz Devman bei paralleen Zugriffen verschiedener Clients auf ein Gerät
  • ok!

• Timestamp-Formate diskutieren und beschließen
  • ok!

• Devman
  • service devman von /opt/acc/cpu aus starten
  • Automatische generierung von *-version-*.hh aus x86.mk bzw. ppc.mk
  • Script reldevman für CPU-weise Releases
  • ok!

• Gerätemodellnummer für devman (model: DMAN_01)
  • ok! PKain

• Die Methoden initDevice(), resetDevice(), getStatus() in VmeDevice sollen mit virtual definiert werden? Damit können sie in GmDevice überschrieben werden, wenn das nötig sein sollte.
  • ok! LH

• Spätestens bei der Übergabe von Raphaels "Linux-Userface" an Ralf H. soll es eine Diskussion/Klärung geben bezüglich der "2 Userfaces" und deren Vereinheitlichung geben. Es besteht ansonsten die Gefahr, dass tatsächlich zwei Userfaces existieren und gepflegt werden müssen.
  • ok! Perspektivisch ist Raphaels Userface das Userface.

• Welche Exceptions sollen vom DeviceAccess-API (auf Client-Seite) kommen? Nur AccDevExceptions oder (besser) verschiedene, also auch z.B. CORBA- bzw. omniORB-Exceptions? Auf jeden Fall müssen die einzelnen Methoden so deklariert werden, dass erkennbar ist, welche Exceptions kommen können. Mit Doxygen fließt das dann automatisch in die Dokumentation mit ein.
  • ok! Es werden nur AccDevExceptions geworfen.

• Dualport-RAM von MX und MD in V09: Strukturen so alignen, dass wieder so viele MAX_LOG_DEVs möglich sind wie unter V08.
  • ok! Erledigt.

• Immer #include <abc.hh> und nicht #include "abc.hh" benutzen.
  • ok!

• Implementieren eines getmsg-Interfaces für Python. Das würde eine Python-C-Erweiterung werden.
  • ok! Einfach mit os.popen3() implementiert. Keine Python-C-Erweiterung notwendig.

• Im Python-Modul 'devacc' müssen noch die Methoden für EFICD eingebaut werden.
  • ok! UK
  • Neue Klasse AccEFICD eingeführt, einzelne Elemente über energy(), focus(), intensity(), cycleNo(), dataId()

• Ist ein periodischer?) Auftrag beendet, weil disconnect() aufgerufen wurde oder weil der Connect-Count erreicht wurde, soll nochmal das Callback des Clients über die Methode exit() mit entsprechender ODA-Message aufgerufen werden. Näheres dazu in der Email "Meeting DEVDESC, PROPDESC, DBRELOAD, SWRELOAD" vom 31.Aug.06. Achtung, das bedeutet eine IDL-Änderung!
  • ok! LH. Ist implementiert.

• Beendet sich ein ConnectThread selbst und nicht über AccDevice::disconnect(), weil z.B. der Ausführungszähler (ConnectThread::_con.count) auf Null heruntergezählt wurde, dann wird der Thread zur Zeit (28.Jul.05) nicht aus der Liste (AccDevice::_connections) ausgetragen.
  • ok! LH. Wird nun generell in ConnectThread::~ConnectThread gemacht.

• Persistente IORs und zwei neue Devman-Startoptionen
  • -t: Devman startet mit transienten IORs, so dass mehrere Devman parallel auf einem Rechner laufen können.
  • -d: Devman läuft mit Log-Level 'Debug'
  • ok! SMa

• Sich selbst beendende Konnektierungen tragen sich nicht aus der Map aus.
  • ok! LH

• Nodal, Milmon und VmeTerm mit neuem Userface linken
  • ok!

• Alarme, die von einer SE kommen, haben falsch terminierte Nomenklaturen, so dass hinter der eigentlichen Nomenklatur oft noch irgendwelche Sonderzeichen auftauchen (siehe z.B. Statusalarme der TR-Magnete im Log vom 22. May 07). Im AlarmHandler ist das soweit wie möglich abgefangen. Aber das reicht offensichtlich nicht aus.
  • ok!

• accdevice-corba.hh|.cc: Die synchronen Methoden read(), write() und call() sind im hh-File, die requestXxx()- und connectXxx()-Methoden aber im cc-File implementiert. Die Implementierungen sollen alle ins cc-File. Laufzeitvorteile wegen inline werden als marginal eingeschätzt.
  • ok!