extraordinary stoc/ thrash ...

[Tomas Hlavaty]

Hi Stephan,

thanks for the very informative long post!

Some time ago we discussed something along the lines of modernizing rdb
related code.

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
> list.

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?

Thank you,

Tomas