App FW Scope and Concept - Review

25

There are two commonly-used definitions of an "app": either a user-facing launchable
program (an entry point) such as would appear in launcher menus, or a user-installable
package or bundle such as would appear in an app store.

Comments: 
GN - info - Within GENIVI scope, 'Managed Apps' and 'Native Applications' has been defined
GA: A fair assumption is that a bundle will never contain both managed and
native apps and an app is either native or managed. I think we are fine
with the current definitions and they can be used in combination with the
defintions here without any conflict between them.
GA: A clear definition of "bundle" would help here (because of later usage e.g. entry-points)
GM: Please clarify how this definition is related to "Managed Applications" and "Native Applications" as defined inside the GENIVI Reference Architecture
GM: Also "package or bundle" should be better defined (notice that the GENIVI Compliance Specification already defines a "Package Manager")
PW: ‘bundle’ is defined on line 27 as a concept similar to an app on Android, for example. The definition is refined over the course of the document. We could try and expand the summary here a bit.
GA: This week 2016-11-08 it seems we said that Bundle = A collection of zero or more
executable files, zero or more libraries and zero or more meta-data files (for the last case imagine for example a "Skinning/theming bundle containing Icon graphics and configuration files only.". In an app store what would be presented to the user as one app would technically be downloaded as one bundle of files.

Extracted requirement:

28

A user-installable bundle would most commonly have exactly one entry point. However, it
might not have any entry points at all, for example if it is a theme or some other extension
for the operating system. Conversely, it might have more than one entry point: for example,
a user-installable bundle for an audio player might contain separate menu items for music
and audiobooks, launching different executables or the same executable in different modes
to provide an appropriate UX for each use-case.

Comments:
GN : Ok, Multi entry points for Apps need to be translated into requirement.
GA: Put definitions at top, e.g. what is a bundle according to our previous discussions.

Extracted requirement:

34

In this document, when we need to distinguish between the two meanings,
we will say that a user-installable bundle contains zero or more entry
points. Entry points are similar in scope to Android activities.

Comments:
GN :OK
GA: I am still not sure that the Android comment helps.
From android docs: "An Android Activity is an application
component that provides a screen with which users can interact in order to
do something". Activity requires a graphical view? Is that also required
for each entry point? Let's put down an actual definition table at the
start of this document - for bundles, entry-points, etc.
PW: You're right. Entry points do not require a graphical view. I agree with
putting a definition of entry points at the start of the document.

Extracted requirement:

37

Some vendors might decide to restrict the apps available in their app
stores to have at most one entry point, but that is a policy decision by
those vendors and should not be reflected in the more general app
framework.

Comments:
GN : Should vendor specific config be a part of manifest?
PW: Vendor-specific configuration should be a part of the vendor’s platform policy, which will be encoded in their app store guidelines, and implementations of vendor-specific components in the platform. Manifests contain metadata, which should be kept separate from policy. It would be redundant to encode a general vendor-wide policy of “maximum number of entry points” in the manifest for each app.
Type: INFO.

Extracted requirement:

40

Entry points might be written as native code (for example compiled from C
or C++), or they might run under an interpreter or JIT in a runtime
environment that provides GUI functionality analogous to native code (for
example if the app is written in Java, Python, or JavaScript for the
node.js, gjs or seed runtime environments), or they might run in a HTML5
runtime environment. We treat all of these as fundamentally similar: they
result in the execution of app-author-chosen code.

Comments:
GN : OK
GA: OK
GM: OK
Type: INFO

Extracted requirement:

46

(Note that whether an app is written in native code has no bearing on
whether it is what GENIVI calls a native application, which is an app that
is built into the platform, or a managed application, which is one of the
user-installable apps discussed here: either may be written in either
native code or an interpreted/JITted environment.)

Comments:
GA: Good paragraph but I would consider if the words "compiled code" are
any help here.
PW: I suspect that ‘compiled code’ was chosen against, because a large variety of programming languages are ‘compiled’, even if the end result is managed or native code. The term ‘native code’ is loosely defined on line 40 — does the definition need to be bolstered?

Extracted requirement:

50

The app framework must be capable of running native-code (C or C++)
executables.

Comments:
GA: Policy decision? If we're aiming for one framework to rule them all, I
guess I agree. If we are aiming for a shared requirement set for many
different environments, it might not be true.
PW: The approach we’ve taken is that applications written in interpreted or managed languages are treated as the combination of their interpreter and the code, where the interpreter is invariably native code. So native code support is always required. However, this would be an unnecessary complication on systems which only have managed/interpreted apps. This could be changed to be a policy detail; I don’t know what the consequences would be for the rest of the document.
GN : OK

Extracted requirement:

51

The app framework must be capable of running programs that require an
interpreter/JIT-based runtime environment such as Java or Python. It may
require that the runtime environment provides suitable library
functionality to work with the framework (for example, if the framework
uses D-Bus for IPC, then it does not need to support runtime environments
that do not have a D-Bus implementation or binding).

Comments:
GA: See previous
GN : OK

Extracted requirement:

56

• The app framework must be capable of running programs that run in a
  HTML5 runtime environment: in other words, it must be possible to package a
  web application into a form suitable to be an app bundle. The entry points
  to an app might include GUIs and/or background services (agents, daemons).

Comments:
GA: See previous
GN : OK

Extracted requirement:

59

• It must be possible for an app to contain zero or more GUI entry
  points. Each of these Application framework concept document might appear
  in menus (see App launching) and/or be available for launching by other
  means (see Document launching, URI launching, Data sharing).

Comments:
GA: See below

Extracted requirement:

64

• It must be possible for an app to contain zero or more background services with no
  GUI, which can be launched for purposes such as Data sharing. For example, a search
  provider for a global search feature similar to GNOME Shell search or Unity Lenses,
  such as the one described in Apertis Global Search design, might be implemented in
  this way.

Comments:
GA: So the definition is that these are not entry-points. Entry-points
require a GUI is the definition

PW: No, the definition on line 59 is that entry points may be GUIs or background services. The definition on line 26 does not contradict this, but could be clarified as it currently sounds like an entry point must have a GUI. That’s not the case.
PW: Note that we could cross-reference this to ~line 28.

Extracted requirement:

69

• It must be possible for the GUIs and background services to be implemented by the
  same executable(s) run with different options, or by separate executables.

Comments:
GA: OK
GM: OK

Extracted requirement:

71

Some vendors might decide to restrict the apps available in their app stores to have
at most one executable, or to have at most one GUI and one non-GUI executable, but
that is a policy decision by those vendors and should not be reflected in the more
general app framework.

Comments:
GA: OK
GN : OK
GM : OK
Type: INFO

Extracted requirement:

75

Each bundle should have bundle metadata to represent the app in situations like an app
store, a system settings GUI or a prompt requesting app permissions.

Comments:
GA: OK
GN : OK
GM : OK
Type: Requirement

Extracted requirement:

77

• As a minimum, this metadata should include a globally unique identifier, an icon,
  and an international (English) name and description.

Comments:
GA: OK
GN : Need to define a minimum set as mandatory requirement including privileges/permissions
Type: REQ

Extracted requirement:

79

• Additionally, app bundles should be able to contain translations (localization) which
  replace the international name and description, and any other fields that are marked
  as translatable (internationalization), when displayed on devices configured for a
  specific language and/or country.

Comments:
GA: OK
GN : OK
GM : OK
Type : REQ

Extracted requirement:

83

• The metadata fields in an entry point should be in line with what is typically present
  in other interoperable package metadata specifications such as freedesktop.org
  AppStream and the parts of Android manifests that do not relate to a specific
  <activity>.

Comments:
GA: OK
GN: OK

Extracted requirement:

87

• The base set of metadata fields should be standardized, in the sense that they are
  described in a vendor-neutral document shared by all GENIVI vendors and potentially
  also by non-GENIVI projects, with meanings that do not vary between vendors. For
  example, AppStream XML would be a suitable implementation.

Comments:
GA: OK
GN:OK
Type:REQ

Extracted requirement:

91

• We anticipate that vendors will wish to introduce non-standardized metadata, either
  as a prototype for future standardization or to support vendor-specific additional
  requirements. It must be possible to include new metadata fields in an entry point,
  without coordination with a central authority.

Comments:
GA: OK
GN:OK
Type:REQ

Extracted requirement:

95

• For example, this could be achieved by namespacing new metadata fields using a
  DNS name (as is done in D-Bus), namespacing them with a URI (as is done in XML), or
  using the X-Vendor-NewMetadataField convention (as is done in email headers, HTTP
  headers and freedesktop.org .desktop files).

Comments:
GA: Discussion point. Shall we define this and if so what to choose?
PW: It should be standardised if and only if the metadata
format is standardised, as discussed on line 87. If so, we recommend
AppStream XML, plus ancillary files for custom metadata.
GA: OK. I propose we make AppStream XML a recommended format. Are there any other format proposals?
PW: None from me. For reference, here's the Apertis specification for it: https://appdev.apertis.org/documentation/bundle-spec.html#bundle-metadata

Extracted requirement: