Re: Efficient UNO component linkage & GC ...

On 12/13/2013 12:02 PM, Michael Meeks wrote:
> On Fri, 2013-12-13 at 11:36 +0100, Stephan Bergmann wrote:
> > To be clear, this is about source files, not installation-/run-time ones.
>
>         Sure - but even so - there are a lot of components ;-)
>
>         xmllint --format services.rdb | grep '<implementation' | wc -l
>         1019
>         git ls-files | grep '\.component' | wc -l
>         270
>
>         I'd prefer not to add (and maintain) another 700 tiny files to git that
> are mostly headers; or did I miss the suggestion ?

Sure.  And I'm not saying at all we shouldn't move ahead, just wanted to 
clarify build vs. runtime here.

>         I guess until we have mergedlibs on Windows, we can't easily dispense
> with the .component files for internal components and just build an
> internal data-structure. Even if we did, I imagine compiling /
> generating that from .component files might be more interesting &
> elegant anyway.

Probably depends on how most elegantly to share the per-service-impl 
info needed by both the service mgr and the impl's XServiceInfo.

>         True - but while we're here - AFAICS we should go further to clean that
> up & make it more efficient =) it's a golden opportunity I think.

Btw, we have rather good conditions there wrt not having to care about 
compatibility too much:

Extension components are restricted to legacy active registration 
(covered by DllComponentLoader calling 
cppu::loadSharedLibComponentFactory w/o prefix) and to the original 
components XML schema (sans prefix attribute) for passive registration. 
 That's all we need to keep stable.

Nowadays, the only code involved for passively registered components are 
cppuhelper/source/servicemanager.cxx reading the .rdb data and passing 
off instantiation requests to cppuhelper/source/shlib.cxx.  For 
historical reasons they do so via a published additional 
cppu::loadSharedLibComponentFactory overload (with additional prefix 
argument), but that communication channel should rather be private.

That is, we can easily extend the components XML schema, even removing 
features again in a later LO version.

Stephan