Return-Path: 
 <bloodhound-dev-return-1201-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 23E70E5BF
	for <apmail-incubator-bloodhound-dev-archive@minotaur.apache.org>;
 Tue, 20 Nov 2012 09:24:39 +0000 (UTC)
Received: (qmail 53146 invoked by uid 500); 20 Nov 2012 09:24:39 -0000
Delivered-To: apmail-incubator-bloodhound-dev-archive@incubator.apache.org
Received: (qmail 53057 invoked by uid 500); 20 Nov 2012 09:24:37 -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 53035 invoked by uid 99); 20 Nov 2012 09:24:36 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Nov 2012 09:24:36 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [209.85.217.175] (HELO mail-lb0-f175.google.com)
 (209.85.217.175)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Nov 2012 09:24:31 +0000
Received: by mail-lb0-f175.google.com with SMTP id gg13so1610173lbb.6
        for <bloodhound-dev@incubator.apache.org>;
 Tue, 20 Nov 2012 01:24:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=mime-version:x-originating-ip:in-reply-to:references:date
         :message-id:subject:from:to:content-type:x-gm-message-state;
        bh=e7jV96gRYj/fV7s6BcbjsYG6pISdj3M5ZcghHbFHMDY=;
        b=Rw5Rt6S/ilGSVnf1vBOTZnUNeHUp4fF9G3rLIUfIayXzqxggG06fcUpXwFNJiRC2wG
         Av8kzo6s7rSfs+zDuFkKiCd1rJR7R4Vietmazmbge+aFLXV+LzQMoF88DgrA1OZfePkn
         jgabyiN5+aoHPkicJvuiOAyyrEN4k3hZFVNG/Pve59JvSrfC3/4WBrSB1o1htfZU+ZEj
         BZOjAWmqu85Q5gnMBH72N0Op7f1UgalY+6VCVY/hBvVpPkQvdZw1APLx+tsIGL6Fh2IW
         +4x64MFyB0T0SPJcAf8Fpb6SVCbb6Doa5kTzX8iVaMV6CKyoYEFEL5zliqJRG+IAtMp6
         2G1w==
MIME-Version: 1.0
Received: by 10.112.45.165 with SMTP id o5mr6048847lbm.74.1353403448219; Tue,
 20 Nov 2012 01:24:08 -0800 (PST)
Received: by 10.112.134.8 with HTTP; Tue, 20 Nov 2012 01:24:08 -0800 (PST)
X-Originating-IP: [188.196.38.113]
In-Reply-To: 
 <CAGMZAuOHS95wJavkDfukcOfswO1GMcAxjBiEiK3-AV7gHC2bJQ@mail.gmail.com>
References: 
 <CAGMZAuOke7gFCy-P5quJcnBABQNV_LOLP-rHmUdJqgDfkBGoWw@mail.gmail.com>
	<50AA14CE.8010601@wandisco.com>
	<CAGMZAuOHS95wJavkDfukcOfswO1GMcAxjBiEiK3-AV7gHC2bJQ@mail.gmail.com>
Date: Tue, 20 Nov 2012 10:24:08 +0100
Message-ID: 
 <CAJSKAsjU6in=8UoH7i1aVXmT5yTPFSYExVMGdbOwxPfP5hJqEg@mail.gmail.com>
Subject: Re: [BEP-0003] Request to reject /ticket/<product prefix>/<sequence
 ID> routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
From: =?UTF-8?Q?Peter_Ko=C5=BEelj?= <peter@digiverse.si>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=bcaec554de2ec4d83a04cee9cb5d
X-Gm-Message-State: 
 ALoCoQmV1DzJqGmzfEem9DD9O1/9+I2YJHGg6kC4aCGKUBnng3h8oldAx18vWyShfYqKRBsDJQKH
X-Virus-Checked: Checked by ClamAV on apache.org

--bcaec554de2ec4d83a04cee9cb5d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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:
> [...]
> >>
> >> 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=3Ddif=
f&version=3D14
> >
> >>> 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 =ABRejected ideas=BB 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
> >
>
> +1
>
> > 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 toda=
y
> .
>

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.


>
> > 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 edgewall.org , yes
>

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.


>
> > 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.
>
> +1
> Nonetheless I'll wait for a while to move that paragraph to =ABrejected
> ideas=BB 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
> ;)
>

Which resources do we have, that actually makes sense having outside the
project in multiproject setup?
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.

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 :(


>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

--bcaec554de2ec4d83a04cee9cb5d--