incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
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 15:58:52 GMT
On 11/21/12, Branko Čibej <brane@wandisco.com> wrote:
> On 21.11.2012 07:07, Olemis Lang wrote:
>> On 11/20/12, Branko Čibej <brane@wandisco.com> wrote:
>>> On 21.11.2012 05:08, Olemis Lang wrote:
>>>> On 11/20/12, Gary Martin <gary.martin@wandisco.com> wrote:
>>>>> On 20/11/12 09:24, Peter Koželj wrote:
>>>>>> On 19 November 2012 16:45, Olemis Lang <olemis@gmail.com> wrote:
>>>>>>> On 11/19/12, Gary Martin <gary.martin@wandisco.com> wrote:
>>>>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>>>>> [...]
>>>>>>>>> On 11/19/12, Apache Bloodhound
>>>>>>>>> <bloodhound-dev@incubator.apache.org>
>>>> [...]
>>>>>>>> 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 edgewall.org migrating towards multi-product deployments
>>       (they have expressed their intentions to do so) , there you have
>>       sub-domains use case .
>>   2. sf.net 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.

AFAICS , not quite , even if Routes is not used . As I was trying to
explain in BEP 3 [1]_ request dispatching goes straight to the product
environment's instance of `trac.web.main.RequestDispatcher` , and
`trac.web.main.dispatch_request` is not aware of products existence .
;)

So , in any case we must improve `trac.web.main.dispatch_request`
either with Routes or without it . Routes would be a well-known and
tested way to match this data , but not the only one for sure .

> 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.
>

understood

> 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.
>

ok .

.. [1] Environment lookup
        (https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003#env-dispatch)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message