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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
