covesa / capicxx-wamp-runtime Goto Github PK

Missing dependencies: msgpack,, maybe also autobahn_cpp?

https://github.com/GENIVI/capicxx-wamp-runtime/blob/f92158f578da3837cde2d70a54de559bf2793d6b/src/CommonAPI/Wamp/WampConnection.cpp#L384

A StubAdapter needs a connection which is properly initialized. This means WampConnection::connect has to be executed successfully. In the current implementation, WampConnection::connect will do some asynchronous steps without blocking. In the generated StubAdapterInternal-classes, there is a busy waiting at the beginning of the provideRemoteMethods() method.

This should be improved, without need for busy waiting.

The realm-concept from Crossbar.io is hardcoded in the Crossbar config file and should not be used for defining CommonAPI addresses.

The README says to do these steps:

$ cd capicxx-wamp-runtime
$ mkdir build

<- Here you must mean to also cd into build/ first, right?

$ cmake -D USE_INSTALLED_COMMONAPI=ON -D CMAKE_INSTALL_PREFIX=/usr/local ..
$ make
$ make install

At the end this is written out:
"Build files have been written to: /home/user/devel/GENIVI/capicxx-wamp-runtime"
<- Note - not written to /build

1. I thought the more common way is that Makefile(s) are generated inside the build/ directory? That seems to be the point of creating the directory and also what I see from other cmake projects.

2. I suppose this way is fine too, but then why not simply "cmake ." in root instead of "cmake .." inside of build...

Currently WampConnection::dispatch uses boost::asio for implementing the main loop (via Autobahn-cpp). This means that when creating multiple connections multiple main loops (?) will be created. This should be reconsidered and maybe reimplemented.

See implementation of Runtime::registerService(..., std::shared_ptr context).

Compare WampFactory hpp/cpp with Factory from capicxx-someip-runtime and update it to reflect changes from 3.1.6 to 3.1.12.

Same with other wamp-runtime classes.