fix baseline build (old cairo) - 'cairo_rectangle_int_t' does not name a type
[LibreOffice.git] / stoc / README
blob58f0c6f1a26aeba83d79fc5ce7d7f6c691881814
1 Registries, reflection, introspection implementation for UNO.
4 The UNO types and services bootstrapping code is very old, and concepts
5 are tightly knit together. Whenever you want to change something you risk
6 backwards incompatibility.  The code causes mental pain, and whenever
7 you need to touch it you want to run away screaming.  One typically ends
8 up doing minimally invasive changes.  That way, you have a chance of
9 surviving the process.  But you also pile up guilt.
11 At the heart of the matter there is the old binary "store" file structure
12 and the XRegistry interface on top of it.  At runtime, both all the UNO
13 type information (scattered across a number of binary rdb files) and
14 all the UNO service information (scattered across a number of rdb files
15 that used to be binary but have been mostly changed to XML now) are
16 represented by a single XRegistry instance each.
18 The way the respective information is represented in the XRegistry
19 interface simply corresponds to the way the information is stored in the
20 binary rdb files.  Those files are designed for storage of hierarchically
21 nested small blobs of information.  Hence, for example information about
22 a UNO interface type com.sun.star.foo.XBar is stored in a nested "folder"
23 with path com - sun - star - foo - XBar, containing little blobs of
24 information about the type's ancestors, its methods, etc.  Similarly
25 for information about instantiable services like com.sun.star.baz.Boz.
27 As there are typically multiple rdb files containing types resp.
28 services (URE specific, LO specific, from extensions, ...), but they need
29 to be represented by a single XRegistry instance, so "nested registries"
30 were invented.  They effectively form a linear list of chaining XRegistry
31 instances together.  Whenever a path needs to be looked up in the top-level
32 registry, it effectively searches through the linear list of nested
33 registries.  All with the cumbersome UNO XRegistry interface between
34 the individual parts.  Horror.
36 When the XML service rdbs were introduced, we chickened out (see above
37 for rationale) and put them behind an XRegistry facade, so that they
38 would seamlessly integrate with the existing mess.  We postponed
39 systematic clean-up to the pie-in-the-sky days of LO 4 (or, "once we'll
40 become incompatible with OOo," as the phrase used to be back then)