Return-Path: 
 <bloodhound-dev-return-1191-apmail-incubator-bloodhound-dev-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 5225CDF76
	for <apmail-incubator-bloodhound-dev-archive@minotaur.apache.org>;
 Mon, 19 Nov 2012 11:16:59 +0000 (UTC)
Received: (qmail 42066 invoked by uid 500); 19 Nov 2012 11:16:58 -0000
Delivered-To: apmail-incubator-bloodhound-dev-archive@incubator.apache.org
Received: (qmail 41609 invoked by uid 500); 19 Nov 2012 11:16:57 -0000
Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:bloodhound-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:bloodhound-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:bloodhound-dev@incubator.apache.org>
List-Id: <bloodhound-dev.incubator.apache.org>
Reply-To: bloodhound-dev@incubator.apache.org
Delivered-To: mailing list bloodhound-dev@incubator.apache.org
Received: (qmail 41581 invoked by uid 99); 19 Nov 2012 11:16:56 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Nov 2012 11:16:56 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of gary.martin@wandisco.com
 designates 209.85.215.47 as permitted sender)
Received: from [209.85.215.47] (HELO mail-la0-f47.google.com) (209.85.215.47)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Nov 2012 11:16:46 +0000
Received: by mail-la0-f47.google.com with SMTP id u2so3379755lag.6
        for <bloodhound-dev@incubator.apache.org>;
 Mon, 19 Nov 2012 03:16:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding
         :x-gm-message-state;
        bh=cNc9J/aewx9JXypqm6V9E7bs324CijgD1VKkbEOwmuI=;
        b=Yamyv75s9P7Fuf4Brn9ZTWZOz3bFUjS5WqXAIikA1cCidu7J5X2zQcW/noizjSrPhf
         5fDetEFkoSRdjNULHB7NxMQaQ/kAEVVRWdP0qjwAio/vCt0mp2AHghv98C6z+Vf5F3qs
         LDwHaLRnE37i+nwjYaTqd8Qp0AmBGkX5s0g+9dOLUM/uH7NLJ2pLu7b9mebsJrPQ8W2w
         9SHTTSlxLohwzLuioGTVPcSJe2vundv7LLAmUXaXncHo8qHnVSVwqHU5EKoFZ4sDMwTC
         tBO7KIKOUcqGZ18e343opHJuk/ajQOndtTDPXO77zVn8rS9JRNdxpnL2pCNlRx2stE7q
         AB6A==
Received: by 10.152.104.115 with SMTP id gd19mr11371511lab.13.1353323785532;
        Mon, 19 Nov 2012 03:16:25 -0800 (PST)
Received: from [192.168.1.70]
 (host86-158-221-135.range86-158.btcentralplus.com. [86.158.221.135])
        by mx.google.com with ESMTPS id ew2sm3473538lbb.2.2012.11.19.03.16.23
        (version=SSLv3 cipher=OTHER);
        Mon, 19 Nov 2012 03:16:24 -0800 (PST)
Message-ID: <50AA14CE.8010601@wandisco.com>
Date: Mon, 19 Nov 2012 11:15:26 +0000
From: Gary Martin <gary.martin@wandisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: [BEP-0003] Request to reject /ticket/<product prefix>/<sequence
 ID> routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
References: 
 <CAGMZAuOke7gFCy-P5quJcnBABQNV_LOLP-rHmUdJqgDfkBGoWw@mail.gmail.com>
In-Reply-To: 
 <CAGMZAuOke7gFCy-P5quJcnBABQNV_LOLP-rHmUdJqgDfkBGoWw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Gm-Message-State: 
 ALoCoQmLr770XIyOQ2D+X1SEHh4RT0mXzoU78/ulQFZd4GlvbGu1GJlOC/xh4wa08ZVMfjbVzbmS
X-Virus-Checked: Checked by ClamAV on apache.org

On 19/11/12 07:04, Olemis Lang wrote:
> I've been working on BEP-0003 recently , adding some routes we should
> support and why . Some details still missing on the subject ,
> especially how all this will work in the context of product
> environments .
>
> ... read below ...
>
> On 11/19/12, Apache Bloodhound <bloodhound-dev@incubator.apache.org> wrote:
>> Page "Proposals/BEP-0003" was changed by olemis
>> Diff URL:
>> <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=14>
>> 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>.
>>
> [...]
>> +In a multi-product configuration product resources should not be accessed
>> using current global URL scheme (i.e.
>> /path/to/bloodhound/<environment>/<realm>/<id>). Since [#permissions
>> products will have their own permissions schema] then requests handled by
>> components in the context of the top-level environment will perform neither
>> the right permissions checks nor even use appropriate settings , and so on
>> ... The same will happen for resources moved between products . In general
>> such requests should be redirected to a URL under the namespace of
>> resource's product.
>>
> 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.

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.

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

Cheers,
     Gary