[Libreoffice] minor idl fixes

[Stephan Bergmann]

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
> want that for the remote Javascript/websockets magic - possibly we could
> 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.

Stephan