mRFC 0019: MidCOM Component Manifest
MidCOM currently detects and loads components by a heuristic approach. A components location is determined by its name, while loading all available components uses some kind of "traverse the source tree" approach. Both solutions are not optimal, in that they hinder flexibility. In addition, it is required to load a component before any meta information can be queried.
With the new ACL framework in place with MidCOM 2.6, this now gives a major performance problem as at this time the framework needs to load all components on every run to ensure the availability of a complete permission set. The solution outlined in this mRFC introduces manifest files which are collected at a central location tha
MidCOM currently detects and loads components by a heuristic approach. A components location is determined by its name, while loading all available components uses some kind of "traverse the source tree" approach. Both solutions are not optimal, in that they hinder flexibility. In addition, it is required to load a component before any meta information can be queried.
With the new ACL framework in place with MidCOM 2.6, this now gives a major performance problem as at this time the framework needs to load all components on every run to ensure the availability of a complete permission set. The solution outlined in this mRFC introduces manifest files which are collected at a central location that should give the additional flexibility needed.
Recommended reading:
Complete Problem Description
With the introduction of virtual groups and access control lists in mRFC 15, components became a way of registering new items to the framework dynamically. In this respect it is important, that the information about the existence of these items is available immediately without much overhead. Since, at this time, a component needs to be loaded before it can actually register something, there is only an inefficient solution at this point (with on-board capabilities): Load all components during startup.
We do not want this, naturally. A component should only have to be loaded if and only if its functionality is actually needed. A rough ballpark figure shows that on a low-end server it can take more then two seconds to load all components, which is unacceptable.
All information we have been talking about so far counts as meta information, which is static to the component. It changes only during development, normally never during run- or even lifetime. The obvious solution for me for this problem is to adopt the concept of a manifest for Midgard Components.
The Component Manifest
The Manifest will contain all meta-information the framework requires for its general treatment of the component. At this time the mainfest will include:
- The name of the component, which will be translated using the components l10n library as it is done now already (l10n libs can be loaded without the component to be loaded).
- All virtual groups and their names defined by the component. The name strings will, as the component name, be translated during runtime using the components l10n library.
- All Access Control List Permissions defined by the component. Again they have to be translateable by the component.
- The path to the components root installation directory. This is purely optional, as the default installation path is derived from the components' name and the root MidCOM installation directory (mimicking the current behavoir).
Other options may be added as needed.
Storage structure
The manifests are stored in the usual array syntax already used by both the configuration system and the datamanger schema storage, for example:
'description' => 'net.nemein.orders',
'vgroups' => Array
(
'mailingcompany' => 'mailing company members virtual group',
'paymentmanagers' => 'payment managers virtual group'
),
'permissions' => Array
(
'mark_orders_as_sent' => MIDCOM_PRIVILEGE_DENY,
'payment_management' => MIDCOM_PRIVILEGE_DENY,
'manage_orders' => MIDCOM_PRIVILEGE_DENY,
),
// This is optional:
// 'installation_path' => '/usr/local/midcom/something/special'
From a CVS point of view, the manifests of all installed components will be stored within the components config directory. However, this is not usable in a running installations, as loading all component manifests would then still require traversal of the installed component tree.
Therefore, a central directory is needed where the manifests of all installed components are collected. For CVS installations, this directory will most probably contain a number of symbolic links to the actual files, while in real life package management driven installations, the manifests could be installed to this location directly, without having to use symbolic linking. This decision is up to the package maintainer, though, I only recommend the direct installation over the symlinks.
The directory where the manifest files are loaded from will be defined in the MidCOM configuration and can thus easily be moved by the package maintainers for example for easier integration into PEAR.
Ideas and Annotations
- I'd like the manifest also to contain info on a suggested icon for the component to use in navigation.
- Take a look at the horde registry classes. They've done something like this for years.
t should give the additional flexibility needed.
Recommended reading:
Complete Problem Description
With the introduction of virtual groups and access control lists in mRFC 15, components became a way of registering new items to the framework dynamically. In this respect it is important, that the information about the existence of these items is available immediately without much overhead. Since, at this time, a component needs to be loaded before it can actually register something, there is only an inefficient solution at this point (with on-board capabilities): Load all components during startup.
We do not want this, naturally. A component should only have to be loaded if and only if its functionality is actually needed. A rough ballpark figure shows that on a low-end server it can take more then two seconds to load all components, which is unacceptable.
All information we have been talking about so far counts as meta information, which is static to the component. It changes only during development, normally never during run- or even lifetime. The obvious solution for me for this problem is to adopt the concept of a manifest for Midgard Components.
The Component Manifest
The Manifest will contain all meta-information the framework requires for its general treatment of the component. At this time the mainfest will include:
- The name of the component, which will be translated using the components l10n library as it is done now already (l10n libs can be loaded without the component to be loaded).
- All virtual groups and their names defined by the component. The name strings will, as the component name, be translated during runtime using the components l10n library.
- All Access Control List Permissions defined by the component. Again they have to be translateable by the component.
- The path to the components root installation directory. This is purely optional, as the default installation path is derived from the components' name and the root MidCOM installation directory (mimicking the current behavoir).
Other options may be added as needed.
Storage structure
The manifests are stored in the usual array syntax already used by both the configuration system and the datamanger schema storage, for example:
'description' => 'net.nemein.orders',
'vgroups' => Array
(
'mailingcompany' => 'mailing company members virtual group',
'paymentmanagers' => 'payment managers virtual group'
),
'permissions' => Array
(
'mark_orders_as_sent' => MIDCOM_PRIVILEGE_DENY,
'payment_management' => MIDCOM_PRIVILEGE_DENY,
'manage_orders' => MIDCOM_PRIVILEGE_DENY,
),
// This is optional:
// 'installation_path' => '/usr/local/midcom/something/special'
From a CVS point of view, the manifests of all installed components will be stored within the components config directory. However, this is not usable in a running installations, as loading all component manifests would then still require traversal of the installed component tree.
Therefore, a central directory is needed where the manifests of all installed components are collected. For CVS installations, this directory will most probably contain a number of symbolic links to the actual files, while in real life package management driven installations, the manifests could be installed to this location directly, without having to use symbolic linking. This decision is up to the package maintainer, though, I only recommend the direct installation over the symlinks.
Ideas and Annotations
- I'd like the manifest also to contain info on a suggested icon for the component to use in navigation.
- Take a look at the horde registry classes. They've done something like this for years.