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 edgewall.org
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
(https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003#url-mapping)
.. [2] Product sub domain
(https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003#deploy-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
[...]/product(s)/<namespace>
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
flexibility.
I've not yet sold myself on all this so are there any other
thoughts/concerns?
Cheers,
Gary
