On 01/13/2012 11:23 AM, Michael Meeks wrote:
Oooh ! :-) it looks really rather nice; how efficient is the compiled
representation ? hopefully much more so than the big chunks of in-lined
UNO-ness that existing code uses :-)
It still uses UNO to access configmgr, but through a simplified
interface (new com.sun.star.configuration.{ReadOnly,ReadWrite}Access
singletons). The main benefit (besides shorter client code) is type
safety -- neither can there be misspellings in the paths of
configuration nodes nor confusion in the values that can be read or
written for those nodes.
I'm excited. Re-thinking my annoyance with getting VCL bootstrapped,
and seeing the level of build parallelism that gnumake exposes - it is
not clear to me that we need to use UNO APIs as a tool to expose more of
that, though clearly some level of circular dependency breaking via
interfaces is useful.
UNO *is* the tool to make functionality available to different
languages, to extensions, and to scripting facilities.
What do I mean ? - I'd like us to consider building configmgr rather
early in the build, and simply linking VCL& above to it, leaving the
UNO API in place for back-compat& extensions, but using a native API
for new code.
If we could combine that with avoiding the need to load types.rdb to do
struct<-> Any handling for PropertyValues - perhaps we could make our
bootstrapping logic, code structure etc. rather simpler for unit tests&
simple test apps in the tree.
I'd prefer to stick to a single configmgr API, and instead make sure
that bootstrapping of tests and "workbench" applications is sufficiently
simple. (And yes, having a look at the latter is still on my todo list.)
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
