Hi Ariel, my somewhat unsorted thoughts on this in the late evening, I might detail this tomorrow.
In general, we need to establish a codex for extensions - the layer structure you cited is open for extensions, and will continue to be, so they will be able to add own content to the DataAccess.xcu/RegisteredNames node. Which means we need to care for this, anyway. (By definition, OOo cannot distinguish from which layer a certain config setting originates: The transparent layering is a (strong, IMO) configuration feature. So, a codex becomes a necessity.) That said, I don't see what the codex shouldn't be: If you register a database, make sure the registration is read-only. Of course this implies - declaring config nodes as read-only must work at all - The registration UI must respect read-only-ness, and not allow the user to change read-only registrations, neither in location nor in name I am tempted to consider the approaches taken in the areas you cited a ... time-pressed solution: - I bet that programmatically, I am still able to change the template paths, even the ones installed by extensions. This is implied by the fact that the "user" layer overrules the "user/uno_packages" layer, and config write access goes to the user layer. - the auto-text example shows that in some places, a "Don't do it"-documentation was the only solution :) - It sounds (I didn't check) as if config data for e.g. template paths is stored in two locations, "internal paths" and "public paths". This duplications of structures is somewhat weird, given that the configuration itself, with layering and read-only-ness, already provides concepts to reach the same (better). I don't question the general rule that we need mechanisms to ensure that extension-provided content is not changed by the user (at least not without exactly knowing what she's doing). I just question the way it was implemented for the cases you cited - it sounds too complex and error-prone to me. For now, I will wait for my arrog^W"I know it better"-attitude to settle down, and see how I think about this topic tomorrow :) Ciao Frank PS: Undoubted facts from your mail: - the DSB should display the content of the "Name" node, not the programmatic registration name - it would be nice to have localized names (though last time we attempted this, in StarOffice 5.2, we ran into trouble. But the framework for implementing this might have matured meanwhile.) Uncertain items from your mail: - localizing paths ... not sure. The documents will get out of sync soon - will this be a problem? Doubted items from your mail: - "the extension developer should have the choice to make the database ... not ... appear in the data source browser." Hmm - not registering it would be the choice here, don't you think? Finally, that's the sense of the DSB: browse the registered databases. -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
