[Libreoffice-commits] .: stoc/README

[Michael Meeks]

 stoc/README |   39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

New commits:
commit 96823006127dbae9dad2833b40c7f9cc7d467ce9
Author: Stephan Bergmann <sbergman at redhat.com>
Date:   Tue Apr 3 12:59:26 2012 +0100

    stoc: add helpful structural documentation from mailing list post.

diff --git a/stoc/README b/stoc/README
index db0e857..58f0c6f 100644
--- a/stoc/README
+++ b/stoc/README
@@ -1 +1,40 @@
 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 LO 4 (or, "once we'll
+become incompatible with OOo," as the phrase used to be back then)