XPLC	"The best way to predict the future is to invent it." -- Alan Kay

Concept and Design

XPLC has a number of goals or ideas that it will follow:

Ease of use for the programmer.
Low overhead.
Portability across platforms and languages.
High level of control for both the programmer and the user.
Transparent expandability.
Blurring the line between an application and a library (both will be components).

The general design borrows some basic element from COM, like interfaces and reference counting, but the core of XPLC is much simpler than the core of COM. Basically, here is the core XPLC concepts:

There is an interface called IObject, that all interfaces are derived from.

There is one single "service manager" object that is obtained through the only function available in the whole API. The service manager is a "finder of objects" that is mainly used through its getObject method. You ask the service manager for an object, and if it is available, it will give it to you.

Of course, there is a number of details, but mostly all of those details are optional to know. For example, you might have noticed that this doesn't cover dynamic loading of components, which is a important for extensibility. Yes, this is normal, because it is optional.

How does the service manager "find" objects? In the simplest possible way, of course, by letting others do the work!

There is an interface called IServiceHandler, which has for sole method the very same getObject method that the service manager has. The service manager maintains a list of service handler objects, and when it is asked for an object, it asks the handlers in its list in turns until one find the wanted object.

This is how most XPLC features are implemented, by providing handlers. This is how dynamic loading of components is provided, by giving the service manager a handler that is capable of finding and activating objects located in dynamically loaded modules.