extraordinary stoc/ thrash ...

[Enrico Weigelt]

> Not in the case of services rdbs.  The information stored there is a
> mapping between (a) service and singleton names (as documented in
> UNOIDL), (b) the implementation names of entities implementing those
> singletons and services, and (c) the software artefacts that contain
> those implementations (dynamic libraries, jars, etc.).

IMHO this information doesnt need to be stored in the registry at all.
In the end, AFAIK, we somewhere have some factory (yet haven't found
where that code actually is, so any help appreciated ;-o) which
instantiates services by the given name. This factory could very
well use some very simple datastructure, just a map. For the builin
components that data could well be compiled-in (eg. via some code
generater as shown by little script i posted yesterday).

What I yet have to find out: where is there instantiation actually
done ? I'd like to change that code in a way, that it first tries
to do the lookup via the generated structures and then fallback
to the registry.

> For types rdbs, on the other hand, the information is indeed
> currently duplicated (triplicated even, given the additional
> representation as Java class files).  Improvement here is
> surely desirable.

Can we directly load it from .idl files or generate a static
data structure from them ?

> My tinkering with a radically simplified component context/service
> manager is going along quite well, btw.  I hope I have enlightening
> numbers soon.

Could you please give me some bit more insight, how that service
manager actually works ?

What's actually happening, from the point where somebody requests some
service until where the requested service class is actually instantiated
(the actual new() operations, in case of c++ ;-)) ?


cu