[PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5

[Michael Stahl]

On 28/03/12 12:26, Tor Lillqvist wrote:
>> MARKER: These services are not intended to be instantiated via their service names.
> 
> How is it in general with service names, if one browses services.rdb
> (either of them), one doesn't have to look long to notice components
> that have identical service names (but different implementation
> names). What does this mean? That they are not supposed to be
> instantiated via service names but via implementation names? Sorry if
> this is a very fundamental question, but I guess I never fully have
> understood UNO...

indeed i've also noticed that; in many cases there are actually multiple
implementations for a given service.  sometimes, these are for generic
things like e.g. enumerations that are only available via some getter or
property from another service, and in that case an implementation name
may or may not exist; but in other cases, the service is actually
instantiated via a factory, and the implementation name is necessary;
the first example that comes to mind is the import/export filter
service, which is implemented once per application per file format, and
of course you want to be using the specific one for the format the user
selected.

> Hmm, I now see that the first such duplicated service name I come
> across just visually browsing is css.frame.ContentHandler, which you
> indeed mark with MARKER in your message.
> 
>> (And there's unfortunately lots of these, needlessly obscuring things in many ways.)
> 
> Indeed. Is there any point at all in cluttering services.rdb (and
> other configuration files?) with these components if they aren't
> looked for from there at run-time anyway?

hmm... good question... perhaps they are necessary for runtime
introspection, i.e. services implement a getSupportedServiceNames method
that returns these and then some introspection thing can look up
metadata from the RDB, like what interfaces and properties may be available.