Problem Description

(April 16 2004, before 1.0-alpha-4)

Much of the HiveMind architecture is predicated upon the idea that no resource should be created until it is needed. Thus service proxies may be created early, but the underlying service implementations (including interceptors) are only created when a method of the service interface is first invoked.

This is not always appropriate:

Attribute Solution

In this solution, the <service-point> element is extended to include a new attribute, create, which would accept the following values:

Development mode could be defined by one of:

There are some conflicts between the create attribute and the service model for the implementation. Today, the primitive service model uses the equivalent of reference, and the other models use the equivalent of invoke.

For services with the threaded or pooled service model, it is (or should it be) necessary that ThreadEventNotifier be invoked after early bird services are created?

Is the order in which services are started relevant? I would hope note.

Configuration Point Solution

In this solution, a new configuration point is defined. Let's call it hivemind.StartupServices. Contributions look like <create-service id="...">.

After the registry is constructed, this extension point is used to force the creation of the services.

This solution works best if the ConditionalContributionsProposal is implemented, and applies to <contribution> elements as well as <implementation> elements.

Again, there's the question of whether order is important.

Discussion

The attribute solution is less verbose but I still find it troubling; I hate all ambiguities and this discord between create and the service model is troubling.

The configuration point solution is more typing, but (if ConditionalContributionsProposal is implemented) seems less ambigous.

Implementation

In 1.0-alpha-5, as configuration hivemind.EagerLoad

ServicePreloadProposal (last edited 2009-09-20 22:01:31 by localhost)