----- config.ini für Mapping von DBus-Gegenstellen: ----- Remaining issues: - Validity checks for read values should be incorporated in DBusAddressTranslator::readValue * Don't forget to ignore any non-"local" domains - Error handling for DBusUtils.h::getBinaryFileName * When one of the defined error codes is thrown - Incorporate checks on binary-file-name-retrieval in unit test. - Incorporate test on cooperation of "Factory::getAvailableServices" and the DBusAddressTranslator - Aufräumen in DBusServiceRegistry! Hier ist scheinbar einiges doppelt und/oder undurchsichtig. * "IsServiceInstanceAlive": Sollte bereits true returnen, wenn nur die Connection dazu lebt. --> Use Cases: # Legacy services implementieren eher nicht "getManagedObjects" # Dienste sollen nicht aufgeweckt werden, wenn z.B. nur ein Proxy für sie angelegt wird --> Macht das den ObjectManager obsolet? --> Können beide Mechanismen sinnvoll nebeneinander existieren? * If service disconnects: Is the proxy correctly marked as not available? Discussion: Does the ServiceRegistry really NEED to ask ALL targets EVERY startup for their managed objects? Alternatives: - On demand, as this is only necessary for the factory method "getAllAvailableServices" - Specific proxy asks only for its own defined service, does not implicitly start the registration of all services with the local ObjectManager ----- MainLoop-Integration: ----- Already working: - Prototypical implementation of MainLoopIntegration * Vorbild vorerst glib * Andere bereits recherchiert - MainLoop * Creation of MainLoopContext within Runtime * Creation of Factories with registered MainLoop * Start automatic dispatch depending on presence of a MainLoopContext * Support of libdbus-watches * Sending and receiving messages by using mainloop iteration TODO: - Workflow, um an den Mainloop-Kontext zu kommen, festlegen - Push auf master: Bei "Refs" statt "Heads" ein "Fork", damits auf Gerrit kommt - Dispatch für synchrone Aufrufe sind immer noch zwei Threads! - connection: dispatch-thread dort rein, var auf false, sync per join - Tests Stückweise wieder integrieren! - Brauchen wir wirklich die CommonAPI::Connection? Ich hoffe ja, dass nicht. - Implementierung der memory-free-functions? Sinnvoll, notwendig? - Verbindungs-Wiederaufbau nach -abriss? Rückmeldung Martin Haefner: 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. Die benutzen ein Leader/Follower Pattern um ihre Requests auf Serverseite auf Threads zu verteilen. Auf Clientseite kann man sich auch einiges denken. Momentan bin ich noch etwas unzufrieden bezgl. des futures das bei den asynchronen Requests verwendet wird. 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 sondern muss im Hintergrund etwas tun. Das hab ich in einer eigenen IPC-Library umgesetzt. Dort gibt es eine generische waitForResponse(Request) Funktion die auf die Antwort wartet, aber eben nirgends blockiert sondern in den Dispatcher reinläuft. 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). ----- "Major Features": ----- * Improved UI for generator, e.g. visible and understandable error messages * CLI für Generator * Vollständige Elimination Middleware-spezifische Generierung * Dynamisches Laden v. ein oder mehereren Middelware-Libraries (Konfiguration und aliases via config) ----- Remains to be sorted/checked/done: ----- Generierte Map-Datentypen: - Für sämtliche legale key-Typen sollte eine Hash-Spezialisierung verfügbar sein, z.B. auch für Variants und Structs. - D-Bus eraubt KEINE non-basic-types als key-Werte (siehe spec)! --> Definitiv nachrangig, aber dennoch wünschenswert, da in Franca erlaubt. Test-Fehler: [ RUN ] ProxyTest.IsAvailableBlocking src/test/DBusProxyTest.cpp:144: Failure Value of: isAvailable Actual: true Expected: registered Which is: false - Vermuteter Grund: In dem Test davor wird die Connection desselben Namens bereits besetzt und nicht abgebaut, bis dieser Test läuft. - Connection sollte bei out-of-scope von allen zusammenhängenden Factory und Proxies eigentlich ebenfalls zerstört werden... Test-Fehler: [ RUN ] DBusMultipleConnectionTest.Broadcast /bin/sh: line 5: 16324 Segmentation fault (core dumped) ${dir}$tst FAIL: DBusMultipleConnectionTest - Einer dieser "Hin und wieder passierts"-Fehler Vererbung von Variants * Per generierung vollspezialisierter equality- und assignment-operatoren * Tests dafür * Fehler im InStream: Spezialisierungen für Vektor und allgemeiner "ByteBuffer"-Fall (welcher std::vector ist) behandeln das selbe Thema doppelt! * Problem auch im OutStream? * Wird der "readByteBufferValue" und "readVectorOfByteBuffers" korrekt aufgerufen? Oder fällt er da auch in die Vektor-Fälle zurück? * Entsprechend: Auflösung von Vektoren von ByteBuffern landen in dem vector> template Fall, nicht in dem vector. Serialisierung: Verwenden des Endianness-Flags von D-Bus! Prüfen und beachten von dieser! Performance tests für Variants? Factory: Template-Vorlagen für Attributs-Extensions vlt auslagern in eigenes file? Bestehende Tests durchgehen und in aktuelle Version überführen! Nicht aktuell: - DBusNameCacheTest - ? * Move Version checking to the ServiceRegistry: Currently, ensuring the interface-version based compatibility of the local proxy and a given remote service would be done asynchronously within the proxy right after its creation. The check should be moved to the service registry, so that a proxy only needs to ask for the locally cached version information of the remote service. According to the current CommonAPI Spec, it is required that a proxy remains "unavailable" when it's counterpart has an incompatible interface version. Feasibility of and alternatives to this approach remain to be determined. * Performance: Check especially message dispatching! Is it possible to do the dispatching without copying the interface name and object path strings? Check (de)serialization, improve where possible. * Dedicated Test of multiple connect/disconnect cycles * DBusProxyHelper.h: // TODO: Must implement available checks on method calls, and wait for valid avalable status in sync case /* * XXX DBusProxy declares a private DBusReadonlyAttribute variable, which * cuases a circular dependency. As a workaround the DBusProxy must be * forward declared and set as default parameter to the template attribute * classes. * * Since DBus*Attribute use the DBusProxyHelper, we have to use the * DBusProxy class as a template typename. */ * DBusMultiEvent.h: /* * XXX DBusProxy declares a private DBusReadonlyAttribute variable, which * cuases a circular dependency. As a workaround the DBusProxy must be * forward declared and set as default parameter to the template attribute * classes. * * Since DBus*Attribute use the DBusProxyHelper, we have to use the * DBusProxy class as a template typename. */ //TODO: if rehashing occurs, then all iterators are invalidated. //TODO: rework with pointers, since this is D-Bus only typedef typename ListenersMap::iterator Subscription; * DBusAttribute.h: /* * XXX DBusProxy declares a private DBusReadonlyAttribute variable, which * causes a circular dependency. As a workaround the DBusProxy must be * forward declared and set as default parameter to the template attribute * classes. */ * DBusServiceRegistry.h: isServiceInstanceAlive: //TODO Fallback for services not in dbus object manager * DBus Generator: implizite Array-Deklaration via "[]" (z.B. UInt32[] in Methoden-Aufruf) unterstützen! - Fall für Structs (und generell): * Methode wird aufgerufen, die eine Basis-Struct akzeptieren * Struct ist tatsächlich eine vererbte Struct * Gesendet wird damit die vererbte Struct, da wir alles über virtual implizit lösen! Problem mit Signatur! Future development (2.1): * Request Name for DBusStubAdapter: The D-Bus specification states that a single D-Bus connection might own multiple names. We have to make sure that when a register request comes from the CommonAPI StubAdapter Factory that we make sure that the name is already owned by our DBusConnection. Probably we'll have to keep a list of all owned names and request a new one on registration if required. * Doxygen in CommonAPI source code. - Handling of D-Bus properties!! Sollte auf Franca attributes gemapped sein (Grund: Interoperabilität) * getValue on attributes is inconsisten with other methods, CallStatus should be in signature not return DBusServiceRegistry.cpp::updateListeners * Sollte der "bool available"-Parameter einen Sinn haben? Prüfen und ihm ggf einen geben, sonst entfernen! ----- "Schöner Wohnen": ----- Angleichung interface InputStream und OutputStream (mal inline, mal nicht, mal als template, mal spezifisch überladen,...)