Re: [Libreoffice] prevent the creation of lockfiles during unit tests

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