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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
