mRFC 0035: On-demand service loading for MidCOM
This is a proposal for moving service and library loading infrastructure in MidCOM 3 to a more on-demand service oriented model.
Background
Currently MidCOM loads a huge number of libraries and services for each request, requiring large amounts of file accesses and PHP parsing. Most of the services loaded are however not really used in a typical request, and so can be seen as being loaded "just in case".
The belief is that this makes the MidCOM environment heavier and more difficult to understand. This proposal outlines how MidCOM could migrate from the current model to a model where services would be loaded when they are used for the first time.
MidCOM service loader
A new class midcom_helper_serviceloader needs to be defined to act as the access point to the MidCOM service system. It will be instantiated as $_MIDCOM->serviceloader at MidCOM start-up.
The service loader should provide two public methods:
boolean can_load($service)
Method for checking if a particular service is available on the system. This would enable components to deal with missing requirements or other situations where some functionality is not available more cleanly.
object load($service)
Method for instantiating an implementation of a particular service.
Inversion of control
An additional benefit of the service loader model is that MidCOM's services can start following the Inversion of Control design pattern.
This means that services are defined by their interface classes, but actual implementation of a service can be chosen by site administrator. This will enable us to easily try and swap between various ways of doing things.
Example: URL name generation can be moved to a midcom_core_service_urlgenerator service. Since the default URL name generator shipping with MidCOM does not deal particularly well with the Georgian language, a web developer deploying Midgard in Georgia can write their own service implementation and just swap that to be used in site configuration.
$GLOBALS['midcom_config_local']['service_midcom_core_service_urlgenerator'] = 'ge_convert_urlgenerator';
Performance
The two-tiered approach of having interface and implementation separately means that two files have to be loaded for each service. This causes a slight performance hit when compared to current approach of one file per service.
However, it is believed that the benefit of loading services only when they're needed and being able to change service implementations on configuration level easily offsets this.
Related tasks
The actual service loader and an URL generator service have already been implemented as an experiment in MidCOM trunk. If this proposal is accepted, all services and "helper libraries" in MidCOM need to be refactored to the new model and components switched to use them.
As this is a big task, the proposal is to switch services to the new model one-by-one, starting from libraries that are used in only few places.
As of 2007-07-19, MidCOM loads 57 files in the midcom.php, with many of them potentially loading sub-dependencies. Most of these could be moved to on-demand handling or removed by the separately proposed DBA rewrite.