extraordinary stoc/ thrash ...
enrico.weigelt at vnc.biz
Tue Apr 3 02:04:03 PDT 2012
> Yes, this is indeed a bit of a tragedy. The relevant UNO types and
> services bootstrapping code is very old, and concepts are tightly
> knit together there, and whenever you want to change something you risk
> backwards incompatibility.
Backwards compatibility to whom ? Binaries ? Source ? User data ?
> At the heart of the matter there is the old binary "store" file
> structure and the XRegistry interface on top of it. At runtime, both
> all the UNO type information (scattered across a number of binary rdb
> files) and all the UNO service information (scattered across a number
> of rdb files that used to be binary but have been mostly changed to XML
> now) are represented by a single XRegistry instance each.
What kind of data do these files hold ?
Is that data somewhat changed after build or does it remain constant ?
> The way the respective information is represented in the XRegistry
> interface simply corresponds to the way the information is stored in
> the binary rdb files.
How is that data structured ? How is it accessed, by whom ?
It is ro or rw data ?
Perhaps it could make sense to design a new interface and step by step
get rid of the old one ?
> Hence, for example information about a UNO interface type
> com.sun.star.foo.XBar is stored in a nested "folder" with path
> com - sun - star - foo - XBar, containing little blobs of information
> about the type's ancestors, its methods, etc.
Does that type name necessarily have to have path semantics, or
would a "flat" string key also be fine ?
> As there are typically multiple rdb files containing types resp.
> services (URE specific, LO specific, from extensions, ...), but they
> need to be represented by a single XRegistry instance, so "nested
> registries" were invented. They effectively form a linear list of
> chaining XRegistry instances together. Whenever a path needs to be
> looked up in the top-level registry, it effectively searches through
> the linear list of nested registries.
Does this nested XRegistry have mounting or union semantics ? Or both ?
Can we compile that splitted registry into a big one ?
> When I introduced XML service rdbs, I sort of chickened out (see
> above for rationale) and put them behind an XRegistry facade, so that they
> would seamlessly integrate with the existing mess. I postponed
> systematic clean-up to the pie-in-the-sky days of LO 4 (or, "once
> we'll become incompatible with OOo," as the phrase used to be back then).
Which kind of incompatibility would happen exactly ?
More information about the LibreOffice