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. 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 | www.wandisco.com
