On 11/21/12, Branko Čibej <[email protected]> wrote:
> On 21.11.2012 07:07, Olemis Lang wrote:
>> On 11/20/12, Branko Čibej <[email protected]> wrote:
>>> On 21.11.2012 05:08, Olemis Lang wrote:
>>>> On 11/20/12, Gary Martin <[email protected]> wrote:
>>>>> On 20/11/12 09:24, Peter Koželj wrote:
>>>>>> On 19 November 2012 16:45, Olemis Lang <[email protected]> wrote:
>>>>>>> On 11/19/12, Gary Martin <[email protected]> wrote:
>>>>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>>>>> [...]
>>>>>>>>> On 11/19/12, Apache Bloodhound
>>>>>>>>> <[email protected]>
>>>> [...]
>>>>>>>> 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:
