Skip to content
Projeler
Gruplar
Parçacıklar
Yardım
Yükleniyor...
Oturum aç / Kaydol
Gezinmeyi değiştir
C
core
Proje
Proje
Ayrıntılar
Etkinlik
Cycle Analytics
Depo (repository)
Depo (repository)
Dosyalar
Kayıtlar (commit)
Dallar (branch)
Etiketler
Katkıda bulunanlar
Grafik
Karşılaştır
Grafikler
Konular (issue)
0
Konular (issue)
0
Liste
Pano
Etiketler
Kilometre Taşları
Birleştirme (merge) Talepleri
0
Birleştirme (merge) Talepleri
0
CI / CD
CI / CD
İş akışları (pipeline)
İşler
Zamanlamalar
Grafikler
Paketler
Paketler
Wiki
Wiki
Parçacıklar
Parçacıklar
Üyeler
Üyeler
Collapse sidebar
Close sidebar
Etkinlik
Grafik
Grafikler
Yeni bir konu (issue) oluştur
İşler
Kayıtlar (commit)
Konu (issue) Panoları
Kenar çubuğunu aç
LibreOffice
core
Commits
96823006
Kaydet (Commit)
96823006
authored
Nis 03, 2012
tarafından
Stephan Bergmann
Kaydeden (comit)
Michael Meeks
Nis 03, 2012
Dosyalara gözat
Seçenekler
Dosyalara Gözat
İndir
Eposta Yamaları
Sade Fark
stoc: add helpful structural documentation from mailing list post.
üst
248edba9
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
39 additions
and
0 deletions
+39
-0
README
stoc/README
+39
-0
No files found.
stoc/README
Dosyayı görüntüle @
96823006
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)
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment