On 12/12/2013 02:47 PM, Michael Meeks wrote:
To split into smaller, unconnected parts would mean to split existing
<component> XML entities into smaller ones, each with its own prefix
That would suck IMHO :-) we have enough scattered files.
To be clear, this is about source files, not installation-/run-time ones.
Or, as you detail below, go further and add more efficient support for
the "single-object-implementation" factory case. (Do you have any idea
whether this is worth it, given we have to continue supporting the other
case for extension-compatibility anyway?)
Sure it's worth it given we're primarily looking for size savings for
mobile; for the Linux case we get only marginal wins here I think.
I'd assume the major size savings would come from leaving out unused
areas of code, and that would already be possible without the "go
further" part.
Incidentally - do we actually use the service information in anger ?
ie. could we not populate / store the data required for the XServiceInfo
interface from the services.rdb at run-time, rather than having it
duplicated in the code ? or is there some benefit to that ?
The duplication is an unfortunate consequence of the move from active to
passive component registration. And as the code was already there, I
never bothered too much to change that to instead re-use the .rdb data.
(Which wouldn't have been easy or elegant, but that might be different
if we represent the .rdb data not in an additional file read at start-up
but in some compiled-in data structures).
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
