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 Mon, 19 Nov 2012 15:45:59 GMT
On 11/19/12, Gary Martin <> wrote:
> On 19/11/12 07:04, Olemis Lang wrote:
>> On 11/19/12, Apache Bloodhound <>
>> wrote:
>>> Page "Proposals/BEP-0003" was changed by olemis
>>> Diff URL:
>>> <>
>>> Revision 14
>>> Comment: [BEP-003] Sample product URL mappings TODO: Detailed request
>>> dispatching
>>> Changes:
>>> -------8<------8<------8<------8<------8<------8<------8<------8<--------
>>> Index: Proposals/BEP-0003
>> [...]
>>>   '''FIXME''' also be addressable through the product URL namespace,
>>> namely
>>> /ticket/<product prefix>/<local ticket id>.
>> Since proposed solution consists in replicating multi-environment
>> setup inside a single environment formerly proposed URL template (i.e.
>> /ticket/<product prefix>/<sequence ID>) seems not to be appropriate
>> for request dispatching, filtering and other processes taking place in
>> the context of product environments.
>> Therefore I'm proposing to move it to «Rejected ideas» section . I
>> look forward to your comments for feedback .
> I am not sure that there is enough justification to allow for allowing a
> path/to/ticket/<product prefix>/<ticketid> - when only considering this
> form for tickets it is certainly possible but we should be making our
> lives easy for the determination of all resources that belong to a
> product so we are probably looking at (in a fairly generalised form):
> pathto/<namespace path>/<product prefix>/pathtoresource


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

> Presumably, running under an appropriate apache configuration, we would
> be able to effectively access the a product without the user having to
> specify the <namespace path> and we could even get the <product prefix>
> specified as a subdomain instead.

like in , yes

> Anyway, with this scheme, the pathtoresource would represent anything
> that could be considered as belonging to the product using the same
> subsequent path as it would if it did not belong to a product.

Nonetheless I'll wait for a while to move that paragraph to «rejected
ideas» section in spite of giving ourselves the chance to consider
more opinions .

> Effectively, this should probably apply to every resource that you can
> have outside of a product (versions, milestones, wiki, etc) but it is
> likely that this is where things begin to get a bit messy when
> considering plugins that are not product-aware.

yes , eventually we need to come up with something regarding shared
resources ... to be discussed in a separate thread , please



Blog ES:
Blog EN:

Featured article:

View raw message