incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <j...@digiverse.si>
Subject Re: [BEP-0003] Request to reject /ticket/<product prefix>/<sequence ID> routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Date Tue, 20 Nov 2012 14:36:31 GMT
On 11/20/12 11:26 AM, Gary Martin 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:
>>> [...]
>>>
>> I am against domins as products. All hell breaks lose when you web page
>> access different domains, which means any interproduct features 
>> (relations,
>> search results...) will be hard to implement or unavailable to the 
>> user in
>> which case we are back to Trac's multi-environments which are the cause
>> that we are having this discussion in the first place.
>
> I would expect that effectively this feature would already be 
> available by providing appropriate configuration of a webserver. Of 
> course, I could be wrong but I thought that it would be possible to 
> use mod_rewrite to match the subdomain to redirect to the appropriate 
> path. This leaves the problem of making sure that inter-product links 
> work properly.
>

I think it should be enough to support one URL resource schema. If 
someone has a wish to map this schema to something else I think that 
should be, as Gary pointed out, possible by using URL rewrite approach.


>>
>>> [...]
>> Which resources do we have, that actually makes sense having outside the
>> project in multiproject setup?

If users are considered resources that would be one. Other than that, 
maybe in the future we'd want to implement global permission schemes, 
notification schemes, etc.

>> And I would also not distinguish between mutli-product and 
>> single-product
>> setup while we are at it. A simple default product could be created 
>> during
>> installation for users that do not have a need for multiple products.
>

+1

> Yes, I remember someone suggesting something like that to me before. 
> Are you suggesting that tickets should always be associated with a 
> product? I don't have a particular problem with allowing for a no 
> product setup as well - or at least the appearance of no product as we 
> should make sure that tickets within the null product are also 
> continuous.
>

+1 for tickets to always be associated with a product. During the 
Bloodhound setup at least 'default' product should be configured.

> Of course, if we always require a product path then we might be able 
> to lose the requirement to mark a path as being for a product.
>
>> I suspect there is no way that we can introduce multiproduct without 
>> making
>> plugins aware of it. Even if we manage to keep API compatibility,
>> multiproduct unaware plugins behavior will very likely be undesired the
>> moment the users creates the second product. So we will need a list 
>> of BH
>> compatible/optimized plugins, at which point we can almost beak Trac API
>> compatibility in exchange for more streamlined implementation and user
>> experience. It is a tough problem to crack :(

+1

Cheers,
Jure



Mime
View raw message