apigear-io/template-cpp14

C++14 technology template

C++ 14 Blueprint

A pure C++ 14 blueprint with CMake build system support. Poco is used for network connections (feature: apigear). The generated code can be enhanced with support for the Conan package manager.

Features

The following list presents a set of features which can be individually enabled in the solution file for code generation.

• api
  Create the plain interface data structure files
• core
  Create a core set of files for json serialization and event handling support implemented
• scaffold
  Create a fully featured project with reference implementations, tests and this README. This is only for convenience. It is also possible to just build and link against e.g. the api and core libraries. And provide a implementation in a completely seperate folder.
• monitor
  Create support libraries for monitoring API traffic
• olink
  Create IPC implementation for ObjectLink. Provides ready to use client and server for your Interfaces Requires: api, core, apigear. For detailed information about information see also "Lifecycle for olink client-server implementation.md"
• mqtt
  Create IPC implementation for MQTT v5. Provides ready to use client and server for your Interfaces Requires: api, core, apigear. For detailed information about information see also the MQTT specification Please note this feature is still experimental.
• apigear
  Create necessary ApiGear support library for extended features like monitoring, olink IPC - needs to be generated for monitor or olink
• examples
  Create simple examples for "How to use" the generated code
• conan
  Create files for conan package manager

template-cpp14's Issues

change example classes

• lines are too long , either use scopes with namespaces in it to skip namespace, or shorten the name by storing it in some kind of map key= module name, value = map <interface, created_objects>, and extract creating those to some function that would return map
• think of how to extend the example, like add some commands? (disconnect/reconnect) fire some signals ?

clean up cmakes

Description

clean up cmakes to inlcude /link smallest possible setup
to make packages out of modules (also with install, so the package contains all the necessary dlls)

Additional Information

No response

Review pointers ownership

Storing raw pointers may lead to some issues
Consider changing to const& or shared_ptr/ unique_ptr depending on lifetime and ownership

Review pimpl class pros and cons

make service adapter thread safe

consider if it is possible or think of task queue in adapter

what if mutex can't be locked (in expected time)

handling for both excpetion and no exception handling code

websocket receiving message - we now use poll with Poco::Timespan(10000)

Client side missing change connection function

The Sink impl (RemoteInterafce) is created with olinkconnetor - which cannot be changed, even if the connection object dies it won't be valid, RemoteInterface would know it is gone, but there is no way to set a new valid one

Align to objectlink-core-cpp changes

apigear-io/objectlink-core-cpp#23

Clean up logging for sink and source implementations- should use same as one given to olink classes (registries and nodes)

POCO client - minimize delays for sending

in OlinkConnection

Make registry optional

OLinkClient(ApiGear::ObjectLink::ClientRegistry& registry);

The registry can be optional (e.g. = null_ptr) and create one if the registry is null.

if (registry == null_ptr) {
  registry = new Registry()
}

handling when connection storage doesn't add a connection - websocket handler response

addConnection should return false if connection cannot be added. The WebSocket handler can check the result and return response with failure.
connected to #47 which mentions mutex locking in general

OlinkConnection - change order of sending link message on re-connect

The link message should be sent before other messages, so the server side could handle them for properly linked object

Why is a sink called remote?

// template-cpp14/goldenmaster/modules/tb_same1_module/tb_same1/generated/olink/remotesameenum2interface.h
class TEST_TB_SAME1_EXPORT RemoteSameEnum2Interface : public ISameEnum2Interface, public ApiGear::ObjectLink::IObjectSink

Why is a Sink called Remote? Why not just SameEnum2InterfaceSink at least then it's more clear what it is. Or call it an Object (e.g. SameEnum2InterfaceObject and the server side impl an SameEnum2InterfaceImpl

Note: Remote is sth for me what lives on the remote side and not what reaches out to the remote side. At least looks confusing for me

Loose module prefix for cpp template

align conan build

• add proper folders to include paths to avoid clashes in case of same interface in different modules
• change file names - case of same name of interface as a module
  align cmake build

enable/disable exceptions

add a flag to enable or disable exceptions
add to generated code version that either logs or throw depending on a flag
also take a look into the json translate functions - they may or may not throw depending on a flag, also how to handle non-throwing case?

refactor client side

part of apigear-io/objectlink-core-cpp#8 task

• check for set up and tear down scenarios - if they are complete
• avoid raw pointers (socket, registry)
• add descriptions
• make code easier to read
• clean up client node interface of possible
• Remove storing m_linkedObjects in OlinkClient -> should be moved to registry . The OlinkClient does not need registry. (C++ template)
• #36 rename olinkClient
• add tests
• use proper version of object-link-core

Improve Publisher Handle Id generation

Publisher (generated/core/interface.publisher.h) class needs to create unique handle id for function subscription,
For now there's plain counter for each property/signal.
Consider more sophisticated solution- templated storage class with a counter inside - add would return the handle - and a storage, could return begin and end iterators, and also provide remove function

Handling big payload

check with poco implementation if it already serves splitting and merging frames into messages for payload exceeding frame size

rename olinkremote to serverConnection & olinkconnection to clientConncetion

multithreading stress tests

add some tests that will test multithreading usage of services, olink client, publisher

clean up conan setup for apigear

Description

currently there is issue with including utilities in other apigear subprojects. The folder structure should be aligned in a way it allows both cmake and conan build in which one can indlude files without relative "one up" ("../") path

Additional Information

No response

Exception handling in core/json.adapter functions

functions may throw when nlohmann can't be translated to requested function,
But the function signature must stay without changes to be easy used in code (nlohmann provides infrastructure for calling j.get() if proper functions provided) - so only thing can be done inside the function is that exception can be catch in a function, and we could return an empty structure + log
Other solution is to leave the handling to function user - but with this approach all the advantage of using those functions automatically is lost - we can as well add function with our signature and call it explicitly
Also what with cases when user disables throwing?

Rename OLinkClient to OLinkConn (or OLinkConnection)

We talk often in terms of client and server, and a Client makes it an OlinkClient makes it different to differentiate between other clients (e.g. ClientNode).

So making sure it just manages the connection would make t more clear.

e.g. OLinkConnection.

Copyrights in files

Make sure all the files have the header with license
TODO think of what else should be inside

• Our own code (apigear, olink) - MIT license
• Generated files - - MIT license

Add unit testing for generated code parts

I think we should have unit tests for all the cpp code. It should not be checked by hand each time we change sth. Also it is a good documentation for user what we suggest do with the code.

• an initial implementation not in template publisher
• try to make a template out of it publisher
• tuner impl
• monitor - an improvement with IInterfaceTrace would help here
  The issue is that we generate a lot of code, and generating tests for each interface each function is too much.
  In my opinion it would be enough to generate test for one interface with signal, method and a property - and test only for one of signals, one of methods, one of properties. If interface does not have all of them, then get next one and test a missing thing from there - but I would start implement that when we switch to new templates language.

extend OlinkConnection (client side) with possibility of subscribing for onConnected on disconnected

allow such example:

ApiGear::PocoImpl::OLinkClient testClient(...);
testClient.onConnected(userCallback);
testClient.onDisconnected(userCallback);
testClient.connectToHost(...);

Client side socket needs to be thread safe

Create subclass to handle subscribable items

just an idea - we have 3 member variable for each subscribable item:
the id, mutex and a map
maybe nicer solution would be class that concatenates them?
it would probably have to have add, remove which would lock() and maybe begin() and end(), or even getCopy 🤔

Originally posted by @dorotaphanSiili in #46 (comment)

extract common websocket functionality from connection handlers

objects that handle server side connection (olinkremote) and client side (olinkconnection) receive and send messages in a same way - this could be extracted to an object like SocketWrapper, which would receive messages in a loop - using a handle message handler and have a writemessage function. The object would take care of thread safety.
Also olinkconnection class does too much. Apart from extracting SocketWrapper it could have SocketWrapperWithMessageQueue - the names are not best choice yet

move to conan2

Description

move to conan 2

Additional Information

No response

Decorator class - how it should be changed

• have in mind changes in trace - will there be some IF in API GEAR
• consider changing to non virtual interface pattern - will be there any improvement
• consider changing according to this diagram
  
  
  Decorator-changed.txt
  decorator_current.txt

refactor server side

part of apigear-io/objectlink-core-cpp#8 task

• check for set up and tear down scenarios - if they are complete
• - avoid raw pointers (HTTPRequestHandlerFactory - the POCO shared ptr, OlinkRemote, HTTPServer, RemoteRegistry )
• - add descriptions also the description for olinkHost that RequestHandlerFactory is owned by POCO server, and similar that OlinkWebSocketHandler will be deleted by it as soon as the request will be handled.
• - make code easier to read
• - std::set<OLinkRemote*> could probably be std::vector, and RequestHandlerFactory should not be a place to keep it - but don't know yet where to? OlinkHost? Registry? something new?
• - fix bug: each property or signal should be broadcasted to all the registered nodes for the source
  not a bug, just mixed roles which class shoudl do what - fixed
  or the methods - reply only to caller node
• - Poco::Net::HTTPRequestHandler* createRequestHandler - handle fail case when we cannot upgrade
• - Shut down scenarios for Server side
• - thread safety when handling messages from clients (this happens in different threads)
  - thread safety on olink host (and realted classes)
  - thread safety in object link core - registry and remote node: locking resources for registry, using weak ptrs apigear-io/objectlink-core-cpp#13
  - thread safety in service #44
• - add tests
• - use proper version of object-link-core

Use shared_ptrs instead of references for publisher/subscriber, monitor etc.

Currently we use mostly references but this can turn out bad in case the original object does not exist anymore.
Therefor we should use shared/weak ptrs instead of pure references.

Tracing of property state change requests

consider tracing request of property changed, not only the actual change

adding a client when source is not added

server is up and running, but registry does not have yet the source. Both remote node and remote registry don't successfully process link message.
The connection is set up so client side won't retry connection, but link message should be send again.
The solution would be

1. service discovery - sending request only when service is available
2. storing sent requests for which we didn't got init message back. Those need to be re-send with some repeat time period

top level cmake - fix fetch_content

generated cmake should have
FetchContent_Declare(module1)
FetchContent_Declare(module2)
FetchContent_MakeAvailable(module1)
FetchContent_MakeAvailable(module2)
instead of
FetchContent_Declare(module1)
FetchContent_MakeAvailable(module1)
FetchContent_Declare(module2)
FetchContent_MakeAvailable(module2)

add maremaid file

add InterfaceBase class

The implementation classes require user to remember to call a publisher on change property or on signal emission. The idea would be to make a base class in core:
InterfaceBase : IInterface
{

• generated virtual functions for changing property marked final;
  - to use by outside classes,
  - implementation calling publisher and protected virtual function : internalPropertyChanged()
• has to have publisher - may be private, there is function get publisher
• protected virtual empty functions internalPropertyChanged which can be overriden in impl
• public non virtual functions emitSignal
  - implement calling publisher
  - call internalEmitSignal()
  - protected virtual empty functions internalEmitSignal() which can be overriden in impl
  also can implement setters and getters, but would need to have data
  }

this way the Base can be always regenerated, and user code is not affected, no way user will forget to call publish.
Main advantage is that the user class will contain only logic.
with emit signals overriding this also might be used for decorator later instead of subscription for signals.

remote interface (olink client side) - thread safety (non blocking) calling methods

using the non async invoke method version calls get on future returned by async invoke method client side - waiting for the result may block other actions for clients of remote interface in same thread. what if connection is lost and there won't be any answer?

float comparison

socket read buffer size is now 1024, we don't handle longer messages

both in server and client side

Fix classes names and descriptions

Align names of files to match class names
Split if necessary to separate files
Add description of class - the purpose, maybe usage
check if we put user description to signals, methods, parameters, class etc.

Rename the interface implementation to `<interface>Impl`

See

// goldenmaster/modules/tb_same1_module/tb_same1/implementation/sameenum1interface.h
class TEST_TB_SAME1_EXPORT SameEnum1Interface : public ISameEnum1Interface

The implementation is meant to be implemented by the server developers. Appending Impl makes it clear it is the implementation.

So

// goldenmaster/modules/tb_same1_module/tb_same1/implementation/sameenum1interface.h
class TEST_TB_SAME1_EXPORT SameEnum1InterfaceImpl : public ISameEnum1Interface

It will be easier to search and to spot. The folder could be also impl instead of implementation which in my taste is much too long.

Client connection reconnect time changes

The reconnect request now is performed with static period of time.
It should try reconnecting first often and then probably double the time with each next request (or after some number of trials)
Also it would be good to make it adjustable from outside maybe passing some reconnection policy? This would be useful also for tests, which check the behavior after reconnection

Add Subscription Token

Publisher class (generated/api/interface/api + impl in core) should return some Token type instead of (unsigned) long type. Best if changed to using SubscriptionToken = unsigned long in API GEAR lib, not repeat the using declaration

[BUG]: apigear-io/template-cpp14: olinkservice fails to compile for simple applications ( ::olinkInvoke has unused arguments )

Description of the bug

When using the cpp14 template, the generated olink service cannot be compiled because fcnArgs is unused.

D:\dev\apigear\ue-int\bulletr1cpp\modules\bulletr1_module\bulletr1\generated\olink\roastsservice.cpp(37,94): error C2220: the following warning is treated as a
n error [D:\dev\apigear\ue-int\bulletr1cpp\build\modules\bulletr1_module\generated\olink\bulletr1-olink.vcxproj]
D:\dev\apigear\ue-int\bulletr1cpp\modules\bulletr1_module\bulletr1\generated\olink\roastsservice.cpp(37,94): warning C4100: 'fcnArgs': unreferenced formal para
meter [D:\dev\apigear\ue-int\bulletr1cpp\build\modules\bulletr1_module\generated\olink\bulletr1-olink.vcxproj]

Steps To Reproduce

1. Define a basic module

schema: "apigear.module/1.0"
name: bulletr1
version: "0.1"

interfaces:
  - name: Roasts
    properties:
      - name: count
        type: int
    operations:
      - name: increment
      - name: decrement

2. Use it in a solution with the apigear-io/template-cpp14 template
3. Generate code for that solution in ApiGear Studio or with the cli
4. Go to the generated folder and run test_conan.bat or test_conan.sh
5. When the build script compiles roastsservice.cpp a compilation error occurs.
6. Succeed in compilation by adding (void)fcnArgs;; to top of function RoastsService::olinkInvoke

Additional Information

No response

Why a source is called adapter?

class TEST_TB_SAME1_EXPORT SameEnum1InterfaceServiceAdapter : public ApiGear::ObjectLink::IObjectSource, public ISameEnum1InterfaceSubscriber

The SameEnum1InterfaceServiceAdapter could just be called SameEnum1InterfaceSource and it becomes a node and an impl interface (e.g. ISameEnum1Interface).

Or you could set the impl later.

e.g. source.SetImplementation(impl * ISameEnum1Interface).

fix naming convention

all the names of methods should go with first lower letter
all the getters should have the get prefix