office-gobmx/stoc
Caolán McNamara 2bafc7384b cid#1545605 COPY_INSTEAD_OF_MOVE
and

cid#1545841 COPY_INSTEAD_OF_MOVE
cid#1554682 COPY_INSTEAD_OF_MOVE
cid#1554686 COPY_INSTEAD_OF_MOVE
cid#1554715 COPY_INSTEAD_OF_MOVE
cid#1554750 COPY_INSTEAD_OF_MOVE
cid#1554759 COPY_INSTEAD_OF_MOVE
cid#1554770 COPY_INSTEAD_OF_MOVE
cid#1554779 COPY_INSTEAD_OF_MOVE
cid#1554794 COPY_INSTEAD_OF_MOVE
cid#1554800 COPY_INSTEAD_OF_MOVE
cid#1554826 COPY_INSTEAD_OF_MOVE
cid#1554836 COPY_INSTEAD_OF_MOVE
cid#1554862 COPY_INSTEAD_OF_MOVE
cid#1554865 COPY_INSTEAD_OF_MOVE
cid#1554872 COPY_INSTEAD_OF_MOVE
cid#1554883 COPY_INSTEAD_OF_MOVE
cid#1554906 COPY_INSTEAD_OF_MOVE
cid#1554921 COPY_INSTEAD_OF_MOVE
cid#1554926 COPY_INSTEAD_OF_MOVE
cid#1554946 COPY_INSTEAD_OF_MOVE
cid#1554956 COPY_INSTEAD_OF_MOVE
cid#1554970 COPY_INSTEAD_OF_MOVE
cid#1554986 COPY_INSTEAD_OF_MOVE
cid#1554991 COPY_INSTEAD_OF_MOVE
cid#1555013 COPY_INSTEAD_OF_MOVE
cid#1555037 COPY_INSTEAD_OF_MOVE
cid#1555050 COPY_INSTEAD_OF_MOVE
cid#1555057 COPY_INSTEAD_OF_MOVE
cid#1555066 COPY_INSTEAD_OF_MOVE
cid#1555067 COPY_INSTEAD_OF_MOVE
cid#1555083 COPY_INSTEAD_OF_MOVE
cid#1555097 COPY_INSTEAD_OF_MOVE
cid#1555135 COPY_INSTEAD_OF_MOVE
cid#1555140 COPY_INSTEAD_OF_MOVE
cid#1555146 COPY_INSTEAD_OF_MOVE
cid#1555148 COPY_INSTEAD_OF_MOVE
cid#1555149 COPY_INSTEAD_OF_MOVE
cid#1555155 COPY_INSTEAD_OF_MOVE
cid#1555157 COPY_INSTEAD_OF_MOVE
cid#1555168 COPY_INSTEAD_OF_MOVE
cid#1555195 COPY_INSTEAD_OF_MOVE
cid#1555196 COPY_INSTEAD_OF_MOVE
cid#1555237 COPY_INSTEAD_OF_MOVE

Change-Id: I90531c19c28dca77fe99c72efdfc0972c311da98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175377
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-10-22 11:56:02 +02:00
..
source cid#1545605 COPY_INSTEAD_OF_MOVE 2024-10-22 11:56:02 +02:00
test
util
CppunitTest_stoc_dump.mk
CppunitTest_stoc_uriproc.mk
IwyuFilter_stoc.yaml
Library_bootstrap.mk
Library_introspection.mk
Library_invocadapt.mk
Library_invocation.mk
Library_javaloader.mk
Library_javavm.mk
Library_namingservice.mk
Library_proxyfac.mk
Library_reflection.mk
Library_stocservices.mk
Makefile
Module_stoc.mk
README.md
unosdk.mk

Registries, Reflection, Introspection Implementation for UNO

The UNO types and services bootstrapping code is very old, and concepts are tightly knit together. Whenever you want to change something you risk backwards incompatibility. The code causes mental pain, and whenever you need to touch it you want to run away screaming. One typically ends up doing minimally invasive changes. That way, you have a chance of surviving the process. But you also pile up guilt.

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.

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. Those files are designed for storage of hierarchically nested small blobs of information. 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. Similarly for information about instantiable services like com.sun.star.baz.Boz.

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. All with the cumbersome UNO XRegistry interface between the individual parts. Horror.

When the XML service .rdbs were introduced, we chickened out (see above for rationale) and put them behind an XRegistry facade, so that they would seamlessly integrate with the existing mess. We postponed systematic clean-up to the pie-in-the-sky days of LibreOffice 4 (or, "once we'll become incompatible with OpenOffice.org," as the phrase used to be back then)