Re: extraordinary stoc/ thrash ...

Hi,

> 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 ?


cu