Apache OpenOffice (AOO) Bugzilla – Issue 110129
configmgr no longer uses ini file and backend UNO API
Last modified: 2017-05-20 11:33:31 UTC
A re-implementation of configmgr has been developed as part of i101955, implemented as CWS sb111 and first integrated into the DEV300_m74 build. In every version of OOo since 1.1.0, the configmgr has been an UNO component with a well-defined interface. In fact, the name of the UNO config service that was loaded by OOo at startup was specified by the CFG_BackendService variable in configmgr(rc|.ini). This made it possible for downstream developers to reimplement configmgr to adapt it to different platforms or environments by simply changing the CFG_BackendService variable. It was also possible for downstream developers to insert new configuration layers into OOo's native configmgr by modifying the CFG_Strata variable in configmgrrc. See for example http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=17300 The new version of configmgr is no longer a pure UNO component, and the configmgr(rc|.ini) file has been completely removed, making it more difficult for downstream developers to adapt OOo to other environments. I would like to request that the reimplemented configmgr be given an UNO interface, just like every other configmgr in OOo since v1.1.0. In viewing the source code, it appears two functions have been added that are directly linked into the main application instead of using an UNO interface: insertExtensionXcsFile and insertExtensionXcuFile. I would like to request that these two functions be reimplemented as an UNO service with a documented interface. (Alternatively, instead of these new functions, unopkg could send an event using com.sun.star.frame.GlobalEventBroadcaster which configmgr picks up using XEventListener and then re-scans the installed extensions directories.) I would also like to request that the configmgrrc and the CFG_BackendService variable be restored to allow OOo to be reconfigured by downstream developers.
What the new configmgr implementation indeed no longer supports are the configmgr ini file in the basis program directory and the ability to hook in additional backends. I was not aware that any client code used those features, so took the liberty to drop them for simpler and potentially more efficient code. The new configmgr still is a UNO component, however (I adapted this issue's summary accordingly). The private C++ interface between configmgr and the extensions manager is an implementation detail; I see no need to revise it. @pulsifer: Do you have any specific usage scenarios that are broken now?
As long as configmgr has a private C++ interface, it cannot be replaced by another UNO component. That of course is the whole point of the UNO framework on which OOo is built and that was used by the former configmgr. It would not be difficult to implement the new functions as an UNO service that is accessed through the UNO service registry (services.rdb), and that would bring the new configmgr on par with the former implementation, which as I mentioned, has been in OOo since v1.1.0. I would also like to request that all of the directory paths used by the new configmgr be put back into variables in the configmgrrc file. This would include all of the paths configmgr searches for .xcd, .xcu and .xcs files, as well as the location where user data is stored. The hard-coding of the paths is a step backward from implementation that was in OOo from v1.0 to up to the latest v3.2 release, and it no doubt had little effect on performance. It again makes OOo less usable by downstream developers and users with non-standard environments. Yes, I do have a particular usage scenario in mind: trying to integrate a custom backend with the new configmgr. This backend was implemented in the manner described by joerg.barfurth@sun.com in the post I linked to above. It has run fine under every version of OOo since v2.0 but does not work with the new configmgr as it is currently implemented in CWS sb111.
@pulsifer: Out of curiosity, what does your additional backend do? ("As long as configmgr has a private C++ interface, it cannot be replaced by another UNO component." I assume this is only of theoretical interest, right?)
>> "As long as configmgr has a private C++ interface, it cannot be replaced >> by another UNO component." > I assume this is only of theoretical interest, right? This is not a theoretical interest. We would use this mechanism to implement our our custom configuration layer, the one we have been using with OOo since v2.0. (The oor:external mechanism you added to the new configmgr is not sufficient for our purposes.) This would be simple change in the new configmgr, and would bring it back on par with the configmgr that has been in OOo since v1.1.0, which was an UNO component with a pure UNO interface.
.
@pulsifer: I'm afraid there is no quick and easy way to bring back the feature of hooking additional backends into the current configmgr. I see two possible ways ahead: 1 Replacing the C++ dependency between configmgr and extension manager with an (unstable, for now) UNO interface would indeed be easy. It would enable replacing all the configmgr service implementations with your own implementations of those services. I am not sure this is what you want to do, though (you do not currently do this, right?). 2 Designing the missing functionality into the new configmgr (using mechanisms that are as close as reasonably possible to the old mechanisms). For this, it would be necessary that you provide a description of the exact services/interfaces you used, and how you modified the configmgr ini file.
After studying this issue for some time, it looks to me fairly straightforward to pull an additional configuration layer into the new configmgr. There are a few related problems I see though: (1) how to notify the configmgr that the data in an external layer has changed (would the external layer be polled, and if so, when?); (2) what would the configmgr do when the external layer has changed (does the entire config data tree need to be rebuilt, or just part of it, or can the rebuild begin with an intermediary result?); and (3) would property change notifications be sent to listeners when data changes in an external layer, and if so, how? My thought is that these issues require some experimentation, and at this point, early in the v3.3 release cycle, I'm willing to do that, try to figure out what will work best, and potentially offer some patch sets or further feedback. I would still like to see the new configmgr have a purely UNO interface though, so it would be easier to extend.
"new configmgr have a purely UNO interface": issue 110491 "I'm willing to do": so passing this issue back to you for now
Reset assigne to the default "issues@openoffice.apache.org".