bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
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:07:43 GMT
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 some
>>>>>> problems when a user chooses a path that is already taken of course.
>>>>> 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 .



Blog ES:
Blog EN:

Featured article:

View raw message