TODO

   1 -----
   2 config.ini für Mapping von DBus-Gegenstellen:
   3 -----
   4 Remaining issues:
   5 - Validity checks for read values should be incorporated in DBusAddressTranslator::readValue
   6   * Don't forget to ignore any non-"local" domains
   7 - Error handling for DBusUtils.h::getBinaryFileName
   8   * When one of the defined error codes is thrown
   9 - Incorporate checks on binary-file-name-retrieval in unit test.
  10 - Incorporate test on cooperation of "Factory::getAvailableServices" and the DBusAddressTranslator
  11 - Aufräumen in DBusServiceRegistry! Hier ist scheinbar einiges doppelt und/oder undurchsichtig.
  12   * "IsServiceInstanceAlive": Sollte bereits true returnen, wenn nur die Connection dazu lebt.
  13     --> Use Cases:
  14         # Legacy services implementieren eher nicht "getManagedObjects"
  15         # Dienste sollen nicht aufgeweckt werden, wenn z.B. nur ein Proxy für sie angelegt wird
  16     --> Macht das den ObjectManager obsolet?
  17     --> Können beide Mechanismen sinnvoll nebeneinander existieren?
  18   * If service disconnects: Is the proxy correctly marked as not available?
  19 Discussion: Does the ServiceRegistry really NEED to ask ALL targets EVERY startup for their managed objects?
  20 Alternatives:
  21 - On demand, as this is only necessary for the factory method "getAllAvailableServices"
  22 - Specific proxy asks only for its own defined service, does not implicitly start the registration
  23   of all services with the local ObjectManager
  24
  25
  26 -----
  27 MainLoop-Integration:
  28 -----
  29 Already working:
  30 - Prototypical implementation of MainLoopIntegration
  31   * Vorbild vorerst glib
  32   * Andere bereits recherchiert
  33 - MainLoop
  34   * Creation of MainLoopContext within Runtime
  35   * Creation of Factories with registered MainLoop
  36   * Start automatic dispatch depending on presence of a MainLoopContext
  37   * Support of libdbus-watches
  38   * Sending and receiving messages by using mainloop iteration
  39
  40 TODO:
  41 - Workflow, um an den Mainloop-Kontext zu kommen, festlegen
  42 - Push auf master: Bei "Refs" statt "Heads" ein "Fork", damits auf Gerrit kommt
  43 - Dispatch für synchrone Aufrufe sind immer noch zwei Threads!
  44 - connection: dispatch-thread dort rein, var auf false, sync per join
  45 - Tests Stückweise wieder integrieren!
  46 - Brauchen wir wirklich die CommonAPI::Connection? Ich hoffe ja, dass nicht.
  47 - Implementierung der memory-free-functions? Sinnvoll, notwendig?
  48 - Verbindungs-Wiederaufbau nach -abriss?
  49 Rückmeldung Martin Haefner:
  50 Bezgl. des Threadings bin ich auch noch gespalten. Hier gibt es niemanden mit dem ich ganz unvoreingenommen drüber diskutieren könnte. Ich hab mir das Modell von ICE angeschaut.
  51 Die benutzen ein Leader/Follower Pattern um ihre Requests auf Serverseite auf Threads zu verteilen. Auf Clientseite kann man sich auch einiges denken.
  52 Momentan bin ich noch etwas unzufrieden bezgl. des futures das bei den asynchronen Requests verwendet wird.
  53 Ich bin irgendwie immernoch der Meinung, dass die ganze API auch in einem einzelnen Thread funktionieren müsste und dann darf der Thread eben nicht in der Waitcondition des Futures blockieren
  54 sondern muss im Hintergrund etwas tun. Das hab ich in einer eigenen IPC-Library umgesetzt.
  55 Dort gibt es eine generische waitForResponse(Request) Funktion die auf die Antwort wartet, aber eben nirgends blockiert sondern in den Dispatcher reinläuft.
  56 Ich hätte daher ein Objekt bevorzugt das zwar das Interface des Futures hat aber eben kein std::future ist und somit im Hintergrund impl. abhängig etwas anderes machen kann (concept).
  57
  58
  59
  60 -----
  61 "Major Features":
  62 -----
  63 * Improved UI for generator, e.g. visible and understandable error messages
  64 * CLI für Generator
  65 * Vollständige Elimination Middleware-spezifische Generierung
  66 * Dynamisches Laden v. ein oder mehereren Middelware-Libraries (Konfiguration und aliases via config)
  67
  68
  69 -----
  70 Remains to be sorted/checked/done:
  71 -----
  72 Generierte Map-Datentypen:
  73 - Für sämtliche legale key-Typen sollte eine Hash-Spezialisierung verfügbar sein, z.B. auch für Variants und Structs.
  74 - D-Bus eraubt KEINE non-basic-types als key-Werte (siehe spec)!
  75   --> Definitiv nachrangig, aber dennoch wünschenswert, da in Franca erlaubt.
  76
  77 Test-Fehler:
  78         [ RUN      ] ProxyTest.IsAvailableBlocking
  79         src/test/DBusProxyTest.cpp:144: Failure
  80         Value of: isAvailable
  81           Actual: true
  82         Expected: registered
  83         Which is: false
  84 - Vermuteter Grund: In dem Test davor wird die Connection desselben Namens bereits besetzt und nicht abgebaut, bis dieser Test läuft.
  85 - Connection sollte bei out-of-scope von allen zusammenhängenden Factory und Proxies eigentlich ebenfalls zerstört werden...
  86
  87 Test-Fehler:
  88         [ RUN      ] DBusMultipleConnectionTest.Broadcast
  89         /bin/sh: line 5: 16324 Segmentation fault      (core dumped) ${dir}$tst
  90         FAIL: DBusMultipleConnectionTest
  91 - Einer dieser "Hin und wieder passierts"-Fehler
  92
  93 Vererbung von Variants
  94 * Per generierung vollspezialisierter equality- und assignment-operatoren
  95 * Tests dafür
  96
  97 * Fehler im InStream: Spezialisierungen für Vektor und allgemeiner "ByteBuffer"-Fall (welcher std::vector<uint8_t> ist) behandeln
  98   das selbe Thema doppelt!
  99 * Problem auch im OutStream?
 100 * Wird der "readByteBufferValue" und "readVectorOfByteBuffers" korrekt aufgerufen? Oder fällt er da auch in die Vektor-Fälle zurück?
 101 * Entsprechend: Auflösung von Vektoren von ByteBuffern landen in dem vector<vector<_Type>> template Fall, nicht in dem vector<ByteBuffer>.
 102
 103 Serialisierung: Verwenden des Endianness-Flags von D-Bus! Prüfen und beachten von dieser!
 104 Performance tests für Variants?
 105 Factory: Template-Vorlagen für Attributs-Extensions vlt auslagern in eigenes file?
 106
 107 Bestehende Tests durchgehen und in aktuelle Version überführen! Nicht aktuell:
 108 - DBusNameCacheTest
 109 - ?
 110
 111
 112 * Move Version checking to the ServiceRegistry:
 113     Currently, ensuring the interface-version based compatibility of the local proxy and
 114     a given remote service would be done asynchronously within the proxy right after its creation.
 115     The check should be moved to the service registry, so that a proxy only needs to ask
 116     for the locally cached version information of the remote service.
 117     According to the current CommonAPI Spec, it is required that a proxy remains "unavailable" when
 118     it's counterpart has an incompatible interface version.
 119     Feasibility of and alternatives to this approach remain to be determined.
 120
 121 * Performance:
 122     Check especially message dispatching! Is it possible to do the dispatching without copying
 123     the interface name and object path strings?
 124     Check (de)serialization, improve where possible.
 125
 126 * Dedicated Test of multiple connect/disconnect cycles
 127
 128 * DBusProxyHelper.h:
 129   // TODO: Must implement available checks on method calls, and wait for valid avalable status in sync case
 130   /*
 131    * XXX DBusProxy declares a private DBusReadonlyAttribute variable, which
 132    * cuases a circular dependency. As a workaround the DBusProxy must be
 133    * forward declared and set as default parameter to the template attribute
 134    * classes.
 135    *
 136    * Since DBus*Attribute use the DBusProxyHelper, we have to use the
 137    * DBusProxy class as a template typename.
 138    */
 139
 140 * DBusMultiEvent.h:
 141   /*
 142    * XXX DBusProxy declares a private DBusReadonlyAttribute variable, which
 143    * cuases a circular dependency. As a workaround the DBusProxy must be
 144    * forward declared and set as default parameter to the template attribute
 145    * classes.
 146    *
 147    * Since DBus*Attribute use the DBusProxyHelper, we have to use the
 148    * DBusProxy class as a template typename.
 149    */
 150   //TODO: if rehashing occurs, then all iterators are invalidated.
 151   //TODO: rework with pointers, since this is D-Bus only
 152   typedef typename ListenersMap::iterator Subscription;
 153
 154 * DBusAttribute.h:
 155   /*
 156    * XXX DBusProxy declares a private DBusReadonlyAttribute variable, which
 157    * causes a circular dependency. As a workaround the DBusProxy must be
 158    * forward declared and set as default parameter to the template attribute
 159    * classes.
 160    */
 161
 162 * DBusServiceRegistry.h:
 163   isServiceInstanceAlive: //TODO Fallback for services not in dbus object manager
 164
 165 * DBus Generator: implizite Array-Deklaration via "[]" (z.B. UInt32[] in Methoden-Aufruf) unterstützen!
 166
 167
 168
 169 - Fall für Structs (und generell):
 170   * Methode wird aufgerufen, die eine Basis-Struct akzeptieren
 171   * Struct ist tatsächlich eine vererbte Struct
 172   * Gesendet wird damit die vererbte Struct, da wir alles über virtual implizit lösen! Problem mit Signatur!
 173
 174
 175
 176
 177 Future development (2.1):
 178
 179 * Request Name for DBusStubAdapter:
 180     The D-Bus specification states that a single D-Bus connection might own multiple names.
 181     We have to make sure that when a register request comes from the CommonAPI StubAdapter
 182     Factory that we make sure that the name is already owned by our DBusConnection.
 183     Probably we'll have to keep a list of all owned names and request a new one on registration
 184     if required.
 185
 186 * Doxygen in CommonAPI source code.
 187
 188 - Handling of D-Bus properties!! Sollte auf Franca attributes gemapped sein (Grund: Interoperabilität)
 189
 190 * getValue on attributes is inconsisten with other methods, CallStatus should be in signature not return
 191
 192
 193
 194 DBusServiceRegistry.cpp::updateListeners
 195 * Sollte der "bool available"-Parameter einen Sinn haben? Prüfen und ihm ggf einen geben, sonst entfernen!
 196
 197
 198
 199 -----
 200 "Schöner Wohnen":
 201 -----
 202 Angleichung interface InputStream und OutputStream (mal inline, mal nicht, mal als template, mal spezifisch überladen,...)