Uploaded image for project: ' AGL Development'
  1. AGL Development
  2. SPEC-1624

libqtappfw: remove per-API dependency

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • None
    • Flounder
    • None

      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 ctxnop 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)

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            ohporter Matt Porter
            sdesneux Stephane Desneux
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: