Hier sollten Dinge stehen, deren Umsetzung potentiell ganz viele Komponenten des Kontrollsystems betreffen. In erster Linie ist an Änderungen von zentralen Schnittstellen zu denken.

IDL-Interface

Änderung Time-Stamp Format (zukünftig mit Datum)

Bisher:

  struct AccStamp {
    unsigned long time;
    unsigned long event;
  };

Zukünftig:

  struct AccStamp {
    struct timeval time;
    unsigned long event;
  };

mit

  struct timeval {
    unsigned long tv_sec;     /* seconds */
    unsigned long tv_usec;    /* microseconds */
  };

• Zeit mit Datum
  • Unix-1970-Format
  • zusätzlich µs
• Platzbedarf: zwei Langworte

Kennzeichnung Userface-Format (V08-kompatibel)

Parameter aufnehmen, der angibt, ob (strukturierte) Daten in dem bisherigen Userface-Format interpretiert werden sollen.

Hintergrund: Das bisherig verwendete Userface kennt nur Arrays von gleichen Datentypen (Ausnahme: Der ganz spezielle Typ 'Structure', der aber auch als Array eines einheitlichen Datentypes, nämlich Byte, übertragen wird). Der neue AccData-Container überträgt beliebig strukturierte Daten.

Mit einem zusätzlichen Parameter (bei allen read/write/call/request.../connect...-Aufrufen anzugeben) kann erreicht werden, dass die Daten in dem bisherigen Userface-Format zu liefern (und zu interpretieren?) sind.

Diesen zusätzlichen Parameter in der Property-Struktur mit unterbringen?

Client-Kennung

Bei Aufrufen mitschicken, wer den Aufruf ausgelöst hat. Etwa

• Client IP-Adresse
  • IPv4 (4 Byte) oder doch gleich IPv6 (16 Byte)
• Client Process-Id
  • vorsichtshalber 8 Byte

Diese zusätzlichen Parameter in der AccessId-Struktur mit unterbringen?

Version des IDL-Interfaces kenntlich machen

IDL-Interface mit einer eindeutigen Kennung versehen, anhand derer überprüft werden kann, ob Client und Server mit derselben Version arbeiten. Sind die Versionen unterschiedlich, darf der Client nicht mit dem Server arbeiten können.

Z.B. in den Interface-Namen eine Versionsnummer mit aufnehmen (CorbaInterface_01, ...). Der Name des Server-Interfaces steht in der IOR. Anhand dieses Namens wird im Client bei der Instantiierung des Geräte-Proxies geprüft, ob Client und Server von demselben Interface ausgehen (beim 'narrow'?) - bei Unterschieden kann man den Proxy ggar nicht erst anlegen.

Da die Interface-Version des Servers auf Client-Seite erkennbar ist (steht in der IOR), könnt man sogar dafür sorgen, dass ein neuerer Client auch mit älteren Servern arbeiten kann (soweit sich die Interfaces umsetzen lassen - aber zumindes die Teile, die sich nicht geändert haben, müssen weiterhin verwendbar sein).

Mehrere Interface-Versionen in demselben Client zu handhaben, ist nicht trivial, aber sehr wohl möglich, wenn es denn mal erforderlich werden sollte. Vor Applikationen sollte sich (weitestgehend) verstecken lassen, wenn mit mehreren Interface-versionen gearbeitet wird, da die Corba-Schnittstelle schon durch eine Schale abgetrennt ist.