Optionality and Dependencies

Optionality

The Embedded Devices (EDs) being the potential platforms of the MEEP 8 platform, embrace a broad range of device types with very varying capabilities. In order to take this into consideration on the one hand, but enable a suitable footprint of the implementation on a concrete device (especially those with very limited memory resources) on the other hand, optionality is a very important characteristic of MEEP 8.

Optionality in MEEP 8 requires to give applications the possibility to declare which optional components of MEEP 8 they do expect in order to be able to run. Therefore the table with Dependency Names for Standard APIs is amended by the following entries :

Additional Dependency Names For MEEP 8 Optional Standard APIs and Components
Dependency Name	Specification Defined In	Version Format
microedition.lui	[LUI], javax.microedition.lui (Line-oriented UI) package	Undefined
microedition.key	[KEY], javax.microedition.key (Key) package	Undefined
microedition.rms	[RMS], javax.microedition.rms (Record Management System) package	Undefined
microedition.media.audio	[MEDIA], javax.microedition.media and javax.microedition.media.control package	Undefined
microedition.io	[IO], javax.microedition.io (Connectivity) package as defined in MEEP 8	Undefined
microedition.io.gcf	Support of GCF, being part of the underlying CLDC 8 configuration.	Undefined
microedition.swm	[SWM], javax.microedition.swm (Application Management System) package	Undefined
microedition.cellular	[CELLULAR], javax.microedition.cellular (Cellular Network) package	Undefined
microedition.event	[EVENT], javax.microedition.event package (Event Management)	Undefined
microedition.power	[POWER], javax.microedition.power package (Power Management)	Undefined
microedition.concurrency	[CONCURRENCY], Application Concurrency	Undefined
microedition.liblets	[LIBLETS], Application Suites and LIBlets	Undefined
microedition.provisioning	[PROVISIONING], Application Provisioning	Undefined
microedition.securityframework	[SECURITY_FRAMEWORK], Security for Applications	Undefined

For the dependency names listed in the table above, there exist also related system properties (see table in the related chapter):

For the optional packages belonging to MEEP 8, there exists one related system property for each package.
For the GCF, being part of CLDC 8, there exist one system property reflecting whether GCF itself is implemented. If this is the case, the implementation of a particular protocol can be checked using the isProtocolSupported method in the javax.microedition.io.Connector class.

If the respective package is implemented in the current implementation of the CLDC-1.8 plus MEEP-8.0 stack, those system properties MUST be available and MUST be true. If the respective package is not implemented, the system property is not defined and a call to System.getProperty for it returns null.

The API of an optional package that is not available in an implementation MUST NOT be provided, and the package MUST NOT exist.

Example: If an implementation decides not to include any user interface package (see below), then neither the javax.microedition.lui nor any API for bit-mapped graphics and UI (defined outside the scope of this specification)is allowed to be existent in this implementation.

The following sections discuss the several options for the customization of a concrete MEEP 8 implementation.

UI Optionality

The existence of a display, and - if available - it's capabilities from a very simple line display without any graphics to a high-end display with graphical capabilities comparable with those of a mobile phone is a degree of freedom for device implementing MEEP 8.

As a consequence, it would make no sense for MEEP 8 to offer one user interface library and force every implementation to include it. The following three options are offered therefore for the customization of MEEP 8:

No User Interface at all. This option is for those devices that do not have a display and for them the implementation of a UI package would make no sense.
The javax.microedition.lui package. This option is for those devices have a simple line display without any graphics capabilities, just offering the display of text messages to the user. Devices may have a built-in display, or the possibility to attach one or more displays not being constantly connected to the device.
Applications requiring the implementation of the LUI package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.lui dependency name as defined here.
And/or: A bit-mapped graphics and UI (defined outside the scope of this specification). This option is for those devices having a full functional graphics display comparable with the one of a mobile phone, it can include any required features needed to use the capabilities of the device, such as a touch screen etc.

After choosing one of the three options, an implementation MUST implement the complete javax.microedition.lui for option two and/or the complete bitmap-oriented graphics package for option 3. When choosing option 1, any user interface functionality MUST NOT be implemented.

Key Optionality

Whether any form of keys is supported by a device implementing MEEP 8 may be different from case to case. The optionality of the Key package (javax.microedition.key) gives an implementation the chance to take this into account.

Persistent Storage Optionality

The usage of persistent storage and a record management system is optional for MEEP 8.

As a consequence, the following two options are offered for the customization of MEEP 8:

No Record Management at all. This option is for those devices that do not have the need to handle persistent data. For this class of devices, it would make no sense to implement a related API, so no API handling persistent storage is available. Before deciding for this option, implementers should consider that due to the application model persistent storage is the only possibility to exchange data between applications in MEEP 8, and that this possibility is also gone when implementing no persistent storage access API.
The javax.microedition.rms package. This option is for those devices with a need of the full functionality of the RMS package.
Applications requiring the implementation of the RMS optional package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.rms dependency name as defined here.

After choosing one of these options, an implementation MUST implement the complete javax.microedition.rms or nothing. When a decision has been made against RMS, any persistent storage management functionality MUST NOT be implemented.

Multimedia Support Optionality

The usage of media support is optional for MEEP 8.

The support of multimedia content is optional for MEEP 8. If multimedia content is supported, this means support just for the audio portion of MMAPI. If a device has a bit-mapped graphics and defines an appropriate UI for it (being out of the scope of this specification), it can decide to implement the full MMAPI as defined in JSR-135 instead, also outside the scope of MEEP 8.

As a consequence, the following two options are offered for the customization of MEEP 8:

No multimedia support at all. This option, that has been already offered in IMP-NG, is for devices without the need for multimedia support including audio support.
The javax.microedition.media and javax.microedition.media.control packages. (Please note that those packages can only by chosen together.) This option - that has already been available in IMP-NG - is for those devices having the need for audio support, as the generation of tones, but do not need the full functionality as defined in JSR-135 including video support.
Applications requiring the implementation of the Audio support optional package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.media.audio dependency name as defined here.
Of course there is also the possibility to implement the full MMAPI as defined in JSR-135 (outside the scope of MEEP 8) instead.
In this case the optional javax.microedition.media and javax.microedition.media.control packages MUST NOT be chosen.
Applications requiring this JSR in order to run , are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the media.api dependency name as defined here.

If choosing option 2, an implementation MUST implement the complete audio subpackage as defined in JSR-135. When choosing option 1, any multimedia support MUST NOT be implemented, or the full MMAPI as defined in JSR-135 has to be implemented outside MEEP 8. Mixtures of those alternatives are not allowed and not necessary.

Connectivity Optionality

Basic connectivity functionality is provided by the javax.microedition.io package of the underlying configuration.

GCF is part of CLDC 8, but not all protocols have to be implemented. If somebody tries to open a connection via an unsupported protocol using Connector.open(), a ConnectionNotFoundException will be thrown.

Applications requiring the implementation of GCF in the underlying CLDC 8 configuration and of certain protocols in order to be able to run, are recommended to declare these requests using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.io.gcf dependency name.

Extended functionality (Inter-MIDlet Communication protocol, PushRegistry) is offered in the javax.microedition.io package of this specification. This package is optional for MEEP 8. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.

Applications requiring the implementation of the MEEP 8 IO package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.io dependency name as defined here.

Non-normative statement: If neither the MEEP 8 IO package nor any of the GCF protocols, classes or interfaces are required, the GCF package itself in CLDC 8 is not needed as well. Platforms including CLDC-1.8 and MEEP-8.0 can decide not to implement it for deployment.

SWM Optionality

Basic AMS functionality as the general lifecycle management of applications is part of any MEEP 8 implementation. Extended functionality (extended suite installation features etc.) is offered in the javax.microedition.swm package of this specification. This package is optional for MEEP 8. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.

Applications requiring the implementation of the SWM package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.swm dependency name as defined here.

Cellular Network Optionality

An API to handle cellular network functionality is offered in the javax.microedition.cellular package of this specification. This package is optional for MEEP 8. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.

Applications requiring the implementation of the Cellular Network package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.cellular dependency name as defined here.

Event Management Optionality

An API to handle events for system state changes and app-to-app communication is offered in the javax.microedition.event package of this specification. This packages is optional for MEEP 8. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.

Applications requiring the implementation of the Event package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.event dependency name as defined here.

Power Management Optionality

An API to handle power management is offered in the javax.microedition.power package of this specification. This packages is optional for MEEP 8. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.

Applications requiring the implementation of the Power Management package in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.power dependency name as defined here.

IO Optionality

An API with special IO operations (PushRegistry, Inter-MIDlet Communication) is offered in the javax.microedition.io package of this specification. This packages is optional for MEEP 8. Implementations on devices without a need for those features MAY decide to not include it. If the package becomes part of the implementation, it MUST be implemented according to the specification: mandatory parts MUST, optional parts MAY be implemented.

Applications requiring the implementation of the IO package (Attention! This refers only to the javax.microedition.io package as defined in MEEP 8, not to the javax.microedition.io package as defined in CLDC 8 / GCF!), in order to be able to run, are recommended to declare this request using the MIDlet-Dependency-<n>, or LIBlet-Dependency-<n> attribute, respectively, using the microedition.io dependency name as defined here.

Concurrency Optionality

MEEP 8 implementations may or may not allow applications to run concurrently. If concurrency is implemented, it MUST follow the rules as defined in the Application Concurrency chapter of this specification. If concurrency is not implemented, any feature making only sense for concurrently running applications (like IMC) haven't to be implemented neither.

Security Framework Optionality

MEEP 8 implementations may or may not implement the Security Framework. If it is decided that this is not needed (e.g. because devices are isolated or have only restricted direct access) it may be useful to resign this feature also to spare memory.

If the Security Framework is implemented, it MUST follow the rules as defined in the Security Framework chapter of this specification.

If the Security Framework is not implemented, there is neither an Authentication Provider nor a Security Policy Provider in place. As a consequence, any application suite can be installed and run without authentication, and there are no restrictions for actions performed by an application.

Provisioning Optionality

MEEP 8 implementations may or may not implement the Provisioning of application suites. If it is decided that this is not needed (e.g. because devices are garnished with pre-installed application suite(s) during manufacturing, and there is no need to add or update application suites during device lifetime) it may be useful to resign this feature also to spare memory.

If Provisioning is implemented, it MUST follow the rules as defined in the Provisioning chapter of this specification. One possibility of realization (and the default one) is the implementation of OTA Provisioning.

LIBlet Support Optionality

MEEP 8 implementations may or may not implement the support of LIBlets.

If the support of LIBlets is implemented, it MUST follow all rules as defined in the Packaging chapter of this specification.

If LIBlets are not supported, all remarks about LIBlets throughout this specification do not apply of course. One consequence is that application suites having a MIDlet-Dependency-<n> attribute with <type> = liblet | service and <level> = required or a MIDlet-Dependency-JAD-URL-<n> attribute in their Application Descriptor or manifest MUST NOT be installed on such an implementation without LIBlet support.

Dependencies

In MEEP 8, a lot of components, features and packages are optional. While this in general means that - with an isolated view onto a particular package or feature - it can be chosen whether it is implemented or not, the relationship between those specification elements is more complex. The reason is, that there exist dependencies between those elements, i.e. a certain feature or package may not be implementable if another feature or package is missing. Implementers will have to take those dependencies into account when configuring their implementation.

The chapter "Profile Sets" gives an (informal) overview about some probably popular combinations of optional components for certain use cases. The possibilities are not limited to those combinations though. Any combination is possible as long as dependencies are taken into account.

The following table gives an overview about those dependencies:

Dependencies of optional MEEP 8 Components

x means the component in the first line of the table is a pre-condition for the component in the first column of the table.

1) Only for the "classical" (OTA) provisioning model, the implementation of GCF and the HTTP and/or HTTPS protocol is a precondition. As MEEP 8 also allows alternative provisioning models (out of the scope of this specification), those may not require anything of it.

2) What's meant with "IO package" here is only the package javax.microedition.io as defined in this specification. This does not include I/O functionality defined in other specifications, in particular not those defined in CLDC 8 (GCF etc.).

The packages javax.microedition.media and javax.microedition.media.control cannot be handled independent on each other, so media optionality includes both packages or none of them.

Please notice that the part of the table above being highlighted gray contains information about dependencies with elements not being part of this specification (GCF is specified in CLDC 8). The information in this gray highlighted part is therefore just informative, not normative (while the dependency information in the white table fields is normative part of this specification).

The interview part of the TCK has to use those dependency definition for checking the conformance of an implementation. If a component is declared to be implemented, then the TCK will assume all components it depends on as also being implemented. If this is not the case, the TCK MUST fail.