REALISING CONDITIONAL PACKAGES IN OSIMIS
----------------------------------------

This short document discusses OSI management conditional packages and suggests
a model for their realisation in OSIMIS through incremental-only changes.


PACKAGES IN GENERAL
-------------------

The functionality of OSI managed object classes comes through groupings
of attributes, actions, notifications and behaviour known as packages.
When referring to the functionality of a class, one essentially refers
to the functionality of its basic package. A class thus consists of
of a set of packages, a basic one (or no basic one at all) and zero
or more conditional ones.

Conditional packages offer the capability of tailoring the functionality
of an object instance at run-time, by allowing a manager to control the
existence of conditional packages when creating that instance. The handle
for this control is the "packages" top class attribute, whose value can be
initialised to the desired set of packages to be supported.

The importance of packages lies in the fact of the run-time tailoring 
offered, as opposed to the compile time one supported by inheritance.
This is particularly important for situations where additional functionality
may incur a space or processing overhead for the managed device and should
be used with caution only when it is needed. In that case, a manager may
delete and re-create an instance with more packages that will supply
information and behaviour it needs.

Note that the tailoring of packages is only allowed at instance creation
as the packages attribute is initialisable but not settable.
Object deletion/re-creation is needed to modify the configuration of packages
of an object instance.  The realisation model suggested below could
allow the dynamic configuration of packages during an instance's lifetime,
but this would increase the complexity of its logic as a "(re-)configure"
additional polymorphic method would be needed for every class.
The benefits of such an approach should be balanced against the introduced
complexity before any proposals to standards etc.

Apart from the general benefits of conditional packages, their support
in OSIMIS is necessary as a lot of standard classes use them and in the
opposite case the deviation from the standards will perpetuate. As an example,
the metric objects use them as a means of configuring the exact functionality
of an object and non-standard additions have been used to overcome the
OSIMIS limitation with respect to packages.


PROPOSED OSIMIS REALISATION MODEL
---------------------------------

Packages have been implicitly supported in OSIMIS in version 3.0 -
the example Unix class had a tide-mark conditional package just to show
how this could be done. In that approach, conditional package code was
put together with that of the basic one and execution was controlled through
boolean flags that were set at creation time, according to the existence
of conditional packages in the instance.

Third parties expressed their doubts for the suitability of that approach,
suggesting that a package is re-usable, so a separate C++ class should
model it, in a similar fashion to classes MO in OSIMIS. Careful consideration
of various conditional packages though shows that their behaviour is very
closely tied to that of the containing class (i.e. basic package) and
re-usability as described above is very difficult to achieve. Furthermore,
even if re-usability was fully possible, the OSIMIS GMS should be
fundamentally restructured to allow the use of packages as separate
C++ objects.

As such, the proposed model here is simply a formalisation of the OSIMIS 3.0
approach through the support of the GDMO compiler and minimal GMS changes.

The GDMO compiler will recognise packages and produce code to initialise
meta-class objects accordingly. It will also produce boolean flags denoting
the presence of a package in the class. Methods to find an attribute, action
and notification of an instance will be modified to check active
packages of that instance in addition to the basic one.

When creating an object, construction takes place in a top-down fashion
in the inheritance hierarchy so a subclass of "top" will know which packages
are present by checking the value of the "packages" attribute and will set
the boolean flags for those in the constructor (compiler produced code).
The rest is up to the user-supplied code which will have access to the
already set boolean flags to tailor its activity accordingly.

