On 11/15/12, Branko Čibej <[email protected]> wrote: > On 16.11.2012 04:58, Olemis Lang wrote: >> On 11/15/12, Apache Bloodhound <[email protected]> >> wrote: >>> Page "Proposals/BEP-0003" was changed by olemis >>> Diff URL: >>> <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=8> >>> Revision 8 >>> Comment: [BEP-0003] Product-specific settings (refs #115) and >>> corollaries >>> mentioned by jure in [/wiki/Proposals/BEP-0003?version=5 version 5] >>> Changes: >>> -------8<------8<------8<------8<------8<------8<------8<------8<-------- >>> Index: Proposals/BEP-0003 >>> >> [...] >> >> In a few words this change provides a solution for most requirements >> specified by jure in version 5 , as all these tasks are accomplished >> by editing trac.ini . It is based on product environments construct . >> >> If you have any comments about this , please reply this e-mail message >> > > It strikes me that this multi-environment proposal makes it relatively > easy to set up completely separate products with their own configuration > (and even their own set of plugins), but ... where do you put common > defaults?
So far I considered global trac.ini file , but it may be a separate ini file for this particular purpose in case that's more appropriate . In the end there will be a single set of default options for sibling products . > Also, managing a zillion .ini files seems like a huge pain, > especially with regards to transaction isolation, data protection > (backup/restore) and replication (e.g., export/import). > > I'd be less nervous about the idea if the .ini files could be mapped > into the database. > Yes , I'm aware of the fact . I just talked about ini files and nothing else because that alternative is straightforward and would reuse existing classes in trac.config module . Nonetheless I added a note on the subject . Please see the last paragraph in «Implementation notes» in config section ( https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003#config ) . It states {{{ Even if the proposal only suggests ini files to store product-specific configuration it is also possible to think of using other configuration repositories (e.g. database, HDFS, remote data repositories). It is a feasible enhancement though details have been omitted. }}} If this is an important matter I could spend some time to describe the approach I have in mind to make this flexibility happen . PS: Indeed once upon a time I had an almost working candidate implementation for #115 based on product environments , but unfortunately my HDD crashed in such a way that it became my most valuable paperweight . Shame on me . :'( -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
