Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.