bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: [BEP-0003] Request to reject /ticket/<product prefix>/<sequence ID> routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Date Wed, 21 Nov 2012 06:27:26 GMT
On 21.11.2012 07:07, Olemis Lang wrote:
> On 11/20/12, Branko Čibej <> wrote:
>> On 21.11.2012 05:08, Olemis Lang wrote:
>>> On 11/20/12, Gary Martin <> wrote:
>>>> On 20/11/12 09:24, Peter Koželj wrote:
>>>>> On 19 November 2012 16:45, Olemis Lang <> wrote:
>>>>>> On 11/19/12, Gary Martin <> wrote:
>>>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>>>> [...]
>>>>>>>> On 11/19/12, Apache Bloodhound <>
>>> [...]
>>>>>>> Up until now I have been considering using 'products' as <namespace
>>>>>>> path> but we might want to choose something else or even consider
>>>>>>> whether this should be configurable. Configurability leads to
>>>>>>> problems when a user chooses a path that is already taken of
>>>>>> I have a idea for this ... I'll write something on the subject later
>>>>>> today
>>>>>> .
>>>>> I do not see a point for having namespace configurable. It complicates
>>>>> things for us and gives user a chance to shoot itself in the foot.
>>> By default they won't , since installer will only provide default well
>>> known routes and they may be similar to multi-environment deployments.
>>> I see that statement somehow different . I'd rather say «I do not see
>>> a point for not having namespace configurable if that's what users
>>> want» .
>> Eh, making things configurable just for the hell of it ("because users
>> want that" or for whatever other foggy reason) is bad design because it
>> complicates your (data) model for no obvious benefit. Of course user
>> will want it if you tell them it's possible.
> Ok , let's see this from a practical perspective .
>   1. Imagine migrating towards multi-product deployments
>       (they have expressed their intentions to do so) , there you have
>       sub-domains use case .
>   2. or somebody else trying to integrate Bloodhound with Allura .
>       In that case Routes will be already acting at a lower level
>       (via Pylons AFAIK) , then you'll have Turbogears ... and in the end ...
>       Bloodhound would be embedded in Allura URL space .
> ... and I'm talking of external routes to reach the product
> environment . Fact is that current solution implemented in
> `trac.web.main.dispatch_request` is very limited and cannot be adapted
> to such use cases .

Both cases can be solved without touching the Bloodhound code. Looking
just at plain vanilla httpd, you have mod_rewrite and mod_proxy; and
there are any number of application-specific ways to achieve the same
result if, e.g., Allura wanted to do the embedding as an add-on feature.

Making the URL space configurable within Bloodhound will only be wasting
time writing partial solutions for a problem which is only relevant for
these kinds of integrations, and /they/ already have much more powerful
tools available to do the same thing than would ever make sense for
Bloodhound proper to provide.

Branko Čibej
Director of Subversion | WANdisco |

View raw message