libqtappfw: remove per-API dependency
Description
Environment
Activity
Tom Rini September 2, 2020 at 1:57 PM
Yes, based on later work in other JIRAs this has been fixed.
Walt Miner September 2, 2020 at 1:38 PM
Can this issue be closed?
Walt Miner August 30, 2018 at 10:11 PM
Adding this topic to the Santa Clara F2F
Jan-Simon Moeller August 24, 2018 at 10:28 AM(edited)
We won't change the situation for FF. But yes, this should be discussed in the SAT for GG.
Stephane Desneux July 31, 2018 at 12:36 AM
Stéphane Desneux I'm afraid you have some misconceptions about how this library works and thus what is or is not potentially problematic. To be specific, no, app developers do not need to pull in useless dependencies.
No misconception here: I perfectly see how it works and I created this ticket because I see some issues.
It's shipped as a shared lib in SDK and in runtime images. But packing all APIs wrappers together in the same lib without any compile-time option to enable/disable a single API and its dependencies is an issue for people developing natively. Basically: the lib is not buildable on a desktop machine (ubuntu, opensuse, fedora ...) because some dependencies may not exist as usual packages. I'd agree that it could be circumvented if the dependencies were directly related to the application being developed but then why libvcard is needed to develop a mediaplayer client and make it run locally ? Please explain my misconception here, if any.
Keep in mind that developing without any SDK can be seen quite often and this is obviously the fastest path to develop/debug apps locally, especially when you're starting to debug QML stuff.
With respect to alternatives, I do want to remind you that we just had an issue where the near universal sentiment was that submodules are bad and do not make life easier.
100% agreed. I want to get rid of submodules. That solution was easier / faster in a first integration round. Now we reach the limit of that model and should move to shared libs / CMake modules.
Discussion on git submodules is off-topic: my point is not on integration details. You make a mistake because libqtappfw has not the same nature than other platform libs: it abstracts applicative APIs and is "on the other side".
So to avoid any misunderstanding, I can try to be clearer: we should separate binaries and libs at least in two classes:
the ones who are part of the platform, which are generic and can be used to builds apps: af-binder, libqt*, qafbwebsocketclient (Qt AFB abstraction - not a shared lib yet, but could be a static lib in SDK or a shared lib in image)
the ones who are part of the applications, are not generic (depend on some APIs, in some versions): libqtappfw, libwindowmanager etc.
I don't see any misconception on my side: a platform lib shouldn't depend on an API provided by a widget. libqtappfw is currently a platform lib and this is against the previous rule. Period.
Note that I'm not arguing about the existence of client libraries for APIs (could be seen as optional regarding the microservices architecture in AGL) and seems to be appreciated somehow by developers who feel "at home". So be it like this, but the right way for the future. So the real topic is how to change how code in libqtappfw is built into apps rather than changing the code of libqtappfw itself.
That said, the code does have some areas that are clearly commented for future improvement and would be happy to spend some cycles on that as part of GG.
You minored the priority for this issue, but the more we develop on the current model, the more difficult it will be to get back on correct tracks (more APIs to "port"). So putting the priority back to 'major' would probably help for GG, because that's a fundamental change to achieve first.
Details
Details
Assignee
Matt PorterReporter
Stephane DesneuxLabels
Affects versions
Priority
Minor
In current implementation (FF.rc2), libqtappfw contains:
abstraction for WS+protocol (based on QtWebsocket)
1 client API (C++ class) per service API, wrapping API calls
This has major drawbacks:
app developers have to pull useless (out-of-scope) dependencies
Example: pull libvcard when developing a mediaplayer app
consequence 1: native development is more difficult (all deps are needed to build libqtappfw)
consequence 2: APIs are potentially linked together at client level => that could create some runtime issues by creating unwanted dependencies (ex: Mediaplayer class could depends on Bluetooth class)
the library is shipped as a platform component where the APIs are implemented through applicative services (agl-service-*). This breaks the effort to separate apps from the platform and makes all CI workflows difficult to handle: API versioniing, QA, CI checks ...
Here are some proposals to be discussed and improved in SAT meeting.
Alternative 1:
use one common static or shared lib for AFB WS protocol shipped with the platform (image or SDK or even git submodule), independently of APIs.
This could be for example the very simple one created by in app-afb-helpers-submodule
make the API abstraction in application itself => remove libqtappfw and simply spread the classes where needed (=in each app sources).
Alternative 2:
same as in alternative 1 for AFB WS protocol abstraction
use one static lib per API, abstracting calls to verbs, potentially usable by multiple client apps. The sources for each client lib must be stored as close to the apps as possible
if only one client app, put the lib sources in the same git repository and build a static lib using a separate subfolder.
if multiple client apps, move eventually that lib folder into the service repository
In any case, there should be no platform library dependency on applicative services APIs.
As a consequence, linking should probably remain static at the moment (or client libs are redistributed for each app, which is useless)