View module in:   cgit


Support for UNOIDL Registry Formats

Library_unoidl contains the unoidl::Manager and unoidl::Provider implementations for the following registry formats:

(While .idl files still contain #include directives for legacy idlc, the source- based formats ignore any preprocessing directives starting with # in the .idl files.) unoidl::Manager::addProvider transparently detects the registry format for a given URI and instantiates the corresponding provider implementation.

Executable_unoidl-write is a helper tool to convert from any of the registry formats to the UNOIDL format. It is used at build-time to compile UNOIDL format .rdb files (that are used at build-time only, or included in installation sets in URE or program/types/ or as part of bundled extensions that are created during the build and not merely included as pre-built .oxt files) from source .idl files. (The SDK still uses idlc and generates legacy format .rdb files for now.)

Executable_unoidl-read is a helper tool to convert from any of the registry formats to the source-file format. It can be used manually after a LibreOffice version update to create new reference registries for Executable_unoidl-check.

Executable_unoidl-check is a helper tool to check that one registry is backwards-compatible with another registry. It is used at build-time to detect inadvertent breakage of the udkapi and offapi APIs.

Specification of the New UNOIDL types.rdb Format

The format uses byte-oriented, platform-independent, binary files. Larger quantities are stored LSB first, without alignment requirements. Offsets are 32 bit, effectively limiting the overall file size to 4GB, but that is not considered a limitation in practice (and avoids unnecessary bloat compared to 64 bit offsets).

Annotations can be added for (non-module) entities and certain parts of such entities (e.g., both for an interface type definition and for a direct method of an interface type definition; the idea is that it can be added for direct parts that forma a “many-to-one” relationship; there is a tradeoff between generality of concept and size of representation, esp. for the C++ representation types in namespace unoidl) and consist of arbitrary sequences of name/value strings. Each name/value string is encoded as a single UTF-8 string containing a name (an arbitrary sequence of Unicode code points not containing U+003D EQUALS SIGN), optionally followed by U+003D EQUALS SIGN and a value (an arbitrary sequence of Unicode code points). The only annotation name currently in use is “deprecated” (without a value).

The following definitions are used throughout:

The file starts with an 8 byte header, followed by information about the root map (unoidl-write generates files in a single depth-first pass, so the root map itself is at the end of the file):

Files generated by unoidl-write follow that by a

"** Created by LibreOffice " LIBO_VERSION_DOTTED " unoidl-write **"

banner (cf. config_host/, as a debugging aid. (Old versions used reg2unoidl instead of unoidl-write in that banner.)

Layout of per-entry payload in the root or a module Map:

Layout of per-entry payload in a constant group Map: