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