You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Olemis Lang <ol...@gmail.com> on 2013/02/06 06:45:14 UTC
[BEP-0003] Handling product env's base_url
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)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [BEP-0003] Handling product env's base_url
Posted by Olemis Lang <ol...@gmail.com>.
On 2/6/13, Gary Martin <ga...@wandisco.com> wrote:
> On 06/02/13 16:35, Andrej Golcov wrote:
>>> 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>
>> Looks like good enough solution for the time of being.
>>
>> As far as I remember, we plan to support product specific ids for
>> tickets. Something like "#XX-1" where "XX" is product ID.
>> How the ticket url should look like in this case:
>> [...]/product(s)/ticket/XX/1
>> or may be
>> [...]/ticket/XX-1 - in this case we need additional mapping but the
>> ticket id is preserved.
>> ?
>>
>> There is another, may be not the best alternative: using slash in
>> product specific ticket id e.g. "#XX/1" that maps directly to
>> [...]/product(s)/ticket/XX/1
>>
>
> All interesting options. I have been assuming that we are working more
> like [...]/product(s)/XX/ticket/1
>
fwiw +1
that's one of them ... maybe the one supported by default .
> Meanwhile, consistency with intertrac links would suggest that XX:#1
> would be a valid reference.
I suggest to discuss wiki syntax in a separate thread , please .
That's another subject
;)
--
Regards,
Olemis.
Re: [BEP-0003] Handling product env's base_url
Posted by Gary Martin <ga...@wandisco.com>.
On 06/02/13 16:35, Andrej Golcov wrote:
>> 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>
> Looks like good enough solution for the time of being.
>
> As far as I remember, we plan to support product specific ids for
> tickets. Something like "#XX-1" where "XX" is product ID.
> How the ticket url should look like in this case:
> [...]/product(s)/ticket/XX/1
> or may be
> [...]/ticket/XX-1 - in this case we need additional mapping but the
> ticket id is preserved.
> ?
>
> There is another, may be not the best alternative: using slash in
> product specific ticket id e.g. "#XX/1" that maps directly to
> [...]/product(s)/ticket/XX/1
>
> Regards, Andrej
All interesting options. I have been assuming that we are working more
like [...]/product(s)/XX/ticket/1
Meanwhile, consistency with intertrac links would suggest that XX:#1
would be a valid reference. I don't mind also supporting XX-1 or other
forms but I wonder if we should just add the alternatives later.
Cheers,
Gary
Re: [BEP-0003] Handling product env's base_url
Posted by Andrej Golcov <an...@digiverse.si>.
> 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>
Looks like good enough solution for the time of being.
As far as I remember, we plan to support product specific ids for
tickets. Something like "#XX-1" where "XX" is product ID.
How the ticket url should look like in this case:
[...]/product(s)/ticket/XX/1
or may be
[...]/ticket/XX-1 - in this case we need additional mapping but the
ticket id is preserved.
?
There is another, may be not the best alternative: using slash in
product specific ticket id e.g. "#XX/1" that maps directly to
[...]/product(s)/ticket/XX/1
Regards, Andrej
Re: [BEP-0003] Handling product env's base_url
Posted by Olemis Lang <ol...@gmail.com>.
On 2/6/13, Gary Martin <ga...@wandisco.com> wrote:
> 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?
Well , actually it does .
;)
[...]
>
> I've not yet sold myself on all this so are there any other
> thoughts/concerns?
>
for the time being that's what I'll consider in the test cases . In
real life a considerable number of deployments I envision will be
using subdomains layout .
--
Regards,
Olemis.
Re: [BEP-0003] Handling product env's base_url
Posted by Gary Martin <ga...@wandisco.com>.
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