bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [BEP-0003] Handling product env's base_url
Date Wed, 06 Feb 2013 11:42:47 GMT
On 06/02/13 05:45, Olemis Lang wrote:
> This is something I wanted to discuss since long time ago but
> postponed the whole thing until really necessary ... i.e. now that I'm
> going to start translating test cases for batch ticket updates , I
> noticed that they make use of environment's href . Therefore I ask :
> Q:
>    - What would be the default approach to specify product environments href ?
> There are some aspects to consider in advance of installing proposed approach :
>    a. it should be prepared to deal with large numbers of products
>    b. ... and still not to represent a big overhead to site admins
>    c. it should be flexible enough to support different kinds
>       of product namespaces [1]_
> The first immediate impression I have is that traditional approach
> (i.e. base_url option in [trac] section) does not scale up to cope
> with (a) and satisfy (b) . Therefore I suggest the following algorithm
> for product env's href resolution .
>    1. if base_url option in [trac] section is set then use it
>    2. ... else , consider a new option **in global environment**
>       (e.g. product_base_href in either [trac] or [multiproduct] sections) .
>       It will consist of a template string that will be expanded
>       using product prefix e.g. http://$product.domain.tld for product
>       sub-domains [2]_ similiar to
>    3. ... else use a (default) built-in product URL expansion rule
>       (e.g. http://domain.tld/path/to/bh/globalenv/products/$product)
>    4. ... or, if global env's base_url option is not set then
>       do exactly the same environments do atm when base_url is missing
> What do you think ?
> PS: I'll summarize the discussion in BEP 3 , for the record .
> PS: PS: resource hierarchies coming soon ... ;)
> .. [1] Product resources namespaces
>         (
> .. [2] Product sub domain
>         (

It looks to me like your algorithm is a little too complicated when we 
can just be defaulting to whatever the normal behaviour for trac is. If 
I rewrite the algorithm to this:

 1. use the product environment's base_href if available, otherwise...
 2. use a [multiproduct] base_href template if available, otherwise...
 3. fall back to normal behaviour with the product at

does that still capture what you are suggesting? I think that I have 
reversed the logic a bit - this way round would give an overriding 
behaviour, allowing for exceptions to more general rules if required. It 
might be better if such overrides are only available for global admins 
to set as it is likely that there would need to be an appropriate 
external setup to support any domain scheme chosen for example.

If we rely on webserver configuration to look after the actual mapping 
away from server:<port>/<environment>/product/<namespace> scheme then we

may not be putting too much work in but we would be introducing a lot of 

I've not yet sold myself on all this so are there any other 


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message