[Libreoffice] minor idl fixes
sbergman at redhat.com
Tue Dec 13 04:18:16 PST 2011
On 12/13/2011 11:15 AM, Michael Meeks wrote:
> On Tue, 2011-12-13 at 00:52 +0100, Tomas Hlavaty wrote:
>> If 200ms is slow, we could split the allpp,idl file into something
>> smaller required at startup and the rest loaded lazily.
> Possibly; or we could invent yet another format for this type
> information. Personally, I'd like to keep the number of representations
> of the same information as low as possible: we already have IDL, we have
> the binaryurp format [ used for IPC on the wire ] (potentially we could
> re-use that?), do we have an XML/text IPC protocol ? I suspect we will
> use a condensed XML format for this that'd be quicker to parse ?
> unclear. Stephan - do you have some ideas ? as soon as I see a yacc
> parser, I see "slow" and "busts the branch predictor" - but perhaps I'm
> paranoid ;-)
Note that URP does not transport any type information. For a first
iteration I would go with a radically stripped down UNOIDL syntax (which
is useful in and of itself, anyway) and .rdb being in that format. If
it is too slow, improve the C++ UNO language binding by redundantly
pre-computing data into a dynamic library.
>> I was under impression that these projects somehow depend on the rdb
>> code, but if they depend on the typedescription api, then it is better
>> then I hoped (if that typedescription api is somehow separate from the
>> rdb file code).
> Sure - there is only one place that we go grubbing with that nasty rdb
> format - and it's at the bottom of the stack :-) if we can hot plug that
> out with something else, life is good :-)
Tomas, if you are interested, you can study how I switched the UNO
service information data from an old .rdb format to an XML-based one at
the bottom of that abstraction stack.
SimpleRegistry::open in stoc/source/simpleregistry/simpleregistry.cxx
first tries the old way (for backwards compatibility with old .oxt
extensions that have their service information still stored in old-style
.rdb files) and if that fails, tries to read via the new TextualServices
stuff. If we have a new format not only for services, but also a new
one for types, we need to extend that code, to either open via
TextualServices or via some new TextualTypes, say. For this, it would
be good if there were an easy and fast discrimination between the two
file formats (like if it starts with "<?xml" pass it to TextualServices,
otherwise to TextualTypes). Since the old concept used the .rdb format
for both service and type information, the code to access either uses
common abstraction layers, that therefore have to be able to deal with
both new formats.
Only once everything works well should we try to get rid of the common
abstraction layers atop the two new formats (the UNO
com.sun.star.registry abstraction stuff). --- Potentially for LO 4, when
we need no longer care about backwards compatibility, which is a pain here.
More information about the LibreOffice