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
  12 -----
  13 MainLoop-Integration:
  14 -----
  15 Already working:
  16 - Prototypical implementation of MainLoopIntegration
  17   * Vorbild vorerst glib
  18   * Andere bereits recherchiert
  19 - MainLoop
  20   * Creation of MainLoopContext within Runtime
  21   * Creation of Factories with registered MainLoop
  22   * Start automatic dispatch depending on presence of a MainLoopContext
  23   * Support of libdbus-watches
  24   * Sending and receiving messages by using mainloop iteration
  25
  26 TODO:
  27 - Workflow, um an den Mainloop-Kontext zu kommen, festlegen
  28 - Push auf master: Bei "Refs" statt "Heads" ein "Fork", damits auf Gerrit kommt
  29 - Dispatch für synchrone Aufrufe sind immer noch zwei Threads!
  30 - connection: dispatch-thread dort rein, var auf false, sync per join
  31 - Tests Stückweise wieder integrieren!
  32 - Brauchen wir wirklich die CommonAPI::Connection? Ich hoffe ja, dass nicht.
  33 - Implementierung der memory-free-functions? Sinnvoll, notwendig?
  34 - Verbindungs-Wiederaufbau nach -abriss?
  35 Rückmeldung Martin Haefner:
  36 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.
  37 Die benutzen ein Leader/Follower Pattern um ihre Requests auf Serverseite auf Threads zu verteilen. Auf Clientseite kann man sich auch einiges denken.
  38 Momentan bin ich noch etwas unzufrieden bezgl. des futures das bei den asynchronen Requests verwendet wird.
  39 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
  40 sondern muss im Hintergrund etwas tun. Das hab ich in einer eigenen IPC-Library umgesetzt.
  41 Dort gibt es eine generische waitForResponse(Request) Funktion die auf die Antwort wartet, aber eben nirgends blockiert sondern in den Dispatcher reinläuft.
  42 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).
  43
  44
  45
  46 -----
  47 "Major Features":
  48 -----
  49 * Improved UI for generator, e.g. visible and understandable error messages
  50 * CLI für Generator
  51 * Vollständige Elimination Middleware-spezifische Generierung
  52 * Dynamisches Laden v. ein oder mehereren Middelware-Libraries (Konfiguration und aliases via config)
  53
  54
  55 -----
  56 Remains to be done:
  57 -----
  58
  59 Problem bei Registrierung mehrerer Interfaces auf selbem ObjectPath (server-seitig):
  60 - Auch "Introspectable" soll damit mehrfach für den selben ObjectPath registriert werden
  61 - Folge: DBusObjectManager beschwert sich wegen:
  62           bool noSuchHandlerRegistered = dbusRegisteredObjectsTable_.find(handlerPath) == dbusRegisteredObjectsTable_.end();
  63           assert(noSuchHandlerRegistered);
  64 - Allgemeineres Konzept f. Introspection muss her (mehrere Interfaces pro ObjectPath müssen unterstützt werden)
  65   * Generiert wird nur noch der "Mittelteil" der Introspection XML
  66   * Ein "globalere" Handler setzt die generierten "Mittelteile" zu einer einzigen Introspection XML zusammen
  67
  68
  69 Generierte Map-Datentypen:
  70 - D-Bus eraubt KEINE non-basic-types als key-Werte (siehe spec)!
  71   --> Verwendung von solchen sollte in Franca verboten oder in CommonAPI erlaubt oder
  72       als Fehler behandelt werden!
  73
  74 Vererbung von Variants
  75 * Per generierung vollspezialisierter equality- und assignment-operatoren
  76 * Tests dafür
  77
  78 * Fehler im InStream und OutStream: Spezialisierungen für Vektor und allgemeiner "ByteBuffer"-Fall
  79   (welcher std::vector<uint8_t> ist) behandeln das selbe Thema doppelt!
  80
  81 Serialisierung: Verwenden des Endianness-Flags von D-Bus! Prüfen und beachten von dieser!
  82
  83 Factory: Template-Vorlagen für Attributs-Extensions vlt auslagern in eigenes file?
  84
  85 Bestehende Tests durchgehen und in aktuelle Version überführen!
  86
  87 * Move Version checking to the ServiceRegistry:
  88     Currently, ensuring the interface-version based compatibility of the local proxy and
  89     a given remote service would be done asynchronously within the proxy right after its creation.
  90     The check should be moved to the service registry, so that a proxy only needs to ask
  91     for the locally cached version information of the remote service.
  92     According to the current CommonAPI Spec, it is required that a proxy remains "unavailable" when
  93     it's counterpart has an incompatible interface version.
  94     Feasibility of and alternatives to this approach remain to be determined.
  95
  96 * Performance:
  97     Check especially message dispatching! Is it possible to do the dispatching without copying
  98     the interface name and object path strings?
  99     Check (de)serialization, improve where possible.
 100
 101 * Dedicated Test of multiple connect/disconnect cycles
 102
 103 * DBus Generator: implizite Array-Deklaration via "[]" (z.B. UInt32[] in Methoden-Aufruf) unterstützen!
 104
 105 - Fall für Structs (und generell):
 106   * Methode wird aufgerufen, die eine Basis-Struct akzeptieren
 107   * Struct ist tatsächlich eine vererbte Struct
 108   * Gesendet wird damit die vererbte Struct, da wir alles über virtual implizit lösen! Problem mit Signatur!
 109
 110 Future development (2.1):
 111
 112 * Request Name for DBusStubAdapter:
 113     The D-Bus specification states that a single D-Bus connection might own multiple names.
 114     We have to make sure that when a register request comes from the CommonAPI StubAdapter
 115     Factory that we make sure that the name is already owned by our DBusConnection.
 116     Probably we'll have to keep a list of all owned names and request a new one on registration
 117     if required.
 118
 119 - Handling of D-Bus properties!
 120   * Nur wenn im deployment gefordert
 121   * Sollten auf Franca attributes gemapped sein
 122
 123 * getValue on attributes is inconsisten with other methods, CallStatus should be in signature not return
 124
 125
 126 -----
 127 "Schöner Wohnen":
 128 -----
 129 Angleichung interface InputStream und OutputStream (mal inline, mal nicht, mal als template, mal spezifisch überladen,...)