extraordinary stoc/ thrash ...
tom at logand.com
Tue Apr 3 14:13:08 PDT 2012
thanks for the very informative long post!
Some time ago we discussed something along the lines of modernizing rdb
I wrote an IDL parser and the java generator unoidl2java is getting
almost complete. I have a few small patches lined up but I'd like to
get the java generator as far as I can so that I get a good picture of
what is it all about. After that I'd like to explore what would be the
best format for a new rdb registry; maybe binary, maybe text, maybe
preprocessed idl or preparsed somehow etc.
>> but writing a duplicate, much simpler xml parser at a higher level to
>> read only the new XML .rdb files and whacking them straight into a
>> hash or two might be a nice easy-hack to have around :-)
I might be missing context here but haven't we discussed some time ago
(probably with Michael) that speed and size are crucial for the
registry? XML might not look like a good idea then.
> I think the problem is not the XML parsing, but the nested XRegistry
Does "nested XRegistry list" mean the registry structure mirroring the
symbol hierarchy of uno packages/classes? Why is that a problem?
> I have a vague idea of placing yet another cppuhelper bootstrap
> mechanism next to the existing ones, which will internally use
> completely different (read: cheap) mechanisms to set up a component
> context and associated service manager. That way, I would avoid most
> of the hassle of having to whack improvements into a rotten framework.
> I'll toy around with that in the next days/weeks. Hang on...
Does it mean this would allow for easier switch to a different registry
format? Or have you already settled on some specific format which would
be part of this another bootstrap mechanism?
More information about the LibreOffice