[putting libreoffice@ back on cc]
On 04/04/2012 11:05 PM, Tomas Hlavaty wrote:
Hi Stephan,
First of all, remember that we have two different scenarios where we
want to replace the old binary rdb format with something else, once
for type information and once for service information.
I see.
(The decision to replace the old binary rdb format with an XML format
for service information was mostly born out of convenience. In
itself, it does not look especially problematic, performance-wise.
While this is certainly open for debate and inspection, I just don't
think it is relevant for the problem at hand.)
But don't we have to maintain this information twice then? Once in the
IDL files and then as XML?
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.).
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.
I think the problem is not the XML parsing, but the nested XRegistry
list.
Does "nested XRegistry list" mean the registry structure mirroring the
symbol hierarchy of uno packages/classes? Why is that a problem?
No. The nesting (or linear list, rather) represents the various files
from which service information is obtained. (And one of the most
important ones, LO's program/services/services.rdb tends to only come
near the very end of that list.)
From this description it seems that the problem is not nesting but
rather _lack_ of nesting (or efficient look up) in the way things are
looked up in the internal representation of rdb files. Is my
understanding correct?
Yes, however you want to put it, the assumption is that retrieving the
relevant information from the data set is sub-optimal. My tinkering
with a radically simplified component context/service manager is going
along quite well, btw. I hope I have enlightening numbers soon.
Stephan
I have a vague idea of placing yet another cppuhelper bootstrap
mechanism next to the existing ones, which will internally use
completely different (read: cheap) mechanisms to set up a component
context and associated service manager. That way, I would avoid most
of the hassle of having to whack improvements into a rotten framework.
The question of on-disk data format (for both type and service
information) would be rather orthogonal to this work.
Great.
Thank you,
Tomas
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
