bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [BEP-0003] Product-specific configuration
Date Fri, 16 Nov 2012 07:10:31 GMT
On 11/15/12, Branko Čibej <> wrote:
> On 16.11.2012 04:58, Olemis Lang wrote:
>> On 11/15/12, Apache Bloodhound <>
>> wrote:
>>> Page "Proposals/BEP-0003" was changed by olemis
>>> Diff URL:
>>> <>
>>> 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 ( )
. 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

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 .




Blog ES:
Blog EN:

Featured article:

View raw message