Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of olemis@gmail.com designates
 209.85.212.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50AB5AF1.9070202@wandisco.com>
References: 
 <CAGMZAuOke7gFCy-P5quJcnBABQNV_LOLP-rHmUdJqgDfkBGoWw@mail.gmail.com>
	<50AA14CE.8010601@wandisco.com>
	<CAGMZAuOHS95wJavkDfukcOfswO1GMcAxjBiEiK3-AV7gHC2bJQ@mail.gmail.com>
	<CAJSKAsjU6in=8UoH7i1aVXmT5yTPFSYExVMGdbOwxPfP5hJqEg@mail.gmail.com>
	<50AB5AF1.9070202@wandisco.com>
Date: Tue, 20 Nov 2012 23:08:42 -0500
Message-ID: 
 <CAGMZAuPwNy4351YQnd6aEhwCZoewzx1+QHMcE2wS3P4Mis731g@mail.gmail.com>
Subject: Re: [BEP-0003] Request to reject /ticket/<product prefix>/<sequence
 ID> routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
From: Olemis Lang <olemis@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/20/12, Gary Martin <gary.martin@wandisco.com> wrote:
> On 20/11/12 09:24, Peter Ko=C5=BEelj 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:
>>> [...]
>>>>> On 11/19/12, Apache Bloodhound <bloodhound-dev@incubator.apache.org>
[...]
>>>
>>>> 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 =C2=ABI do not see
a point for not having namespace configurable if that's what users
want=C2=BB .

>>
>>>> Presumably, running under an appropriate apache configuration, we woul=
d
>>>> 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

All references are relative to environment's base URL . If the
solution pays attention to that then inter-product references will
just work just as InterTrac refrences just work for totally unrelated
Trac environments.

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

Multi-products vs multi-environment is mainly about many envs DBs vs
single products DB . I have deployed multiple web apps at different
sub-domains each interacting with the same DB ... so maybe I am not
seen something obvious ?

> I would expect that effectively this feature would already be available
> by providing appropriate configuration of a webserver.

Some people will need it , yes ;) . That's why it's the first option .
The most evident migration example would be edgewall.org .

Even if I don't think we should suggest sub-domains configuration as
the default option , IMO should make things work in a way that it will
be possible to get it done .

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

Indeed I was thinking of using VirtualHost(s). Routes supports
matching sub-domains via Host and X-Forwarded-Host headers .

> This leaves the problem of making sure that inter-product links work
> properly.
>

Added to my TODO list .

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

In open source communities resource sharing is maybe not a big deal .
Let's focus on a software development enterprise . Everybody in there
will have checkpoints every (three | four ...) months . Major stable
releases will be scheduled to happen at that specific moment too . So
all products will share global milestones e.g. Q1 , Q2 , Q3 , Q4 , and
might have their own local milestones as well (e.g. urgent bug fix
releases , ...) . Q# milestones might be important for other business
experts e.g. management , marketing , strategic planning , ...

Other instances of global resources are users (if considered like so)
and also repositories .

>> And I would also not distinguish between mutli-product and single-produc=
t
>> setup while we are at it.

JFTR , the distinction mentioned in BEP 3 is not about multi-product
vs single-product . It's about multiples environments each one
containing multiple products vs a single environment containing
multiple products . Under some circumstances it is desired to have
explicit boundaries between data (e.g. security levels , data
confidentiality , ... but not limited to those) and environments are
better than products for that separation of concerns .

>> A simple default product could be created
>> during
>> installation for users that do not have a need for multiple products.
>

Also recall that there is another important case , which is
multi-product product support components disabled . Under such
circumstances the global environment will handle it all .

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

That null product is what I call the global environment , which turns
out to be the actual environment (i.e. managed by an instance of
`trac.env.Environment` ).

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

Enhanced routing mechanism adds support for this.

>> I suspect there is no way that we can introduce multiproduct without
>> making
>> plugins aware of it.

Playing with existing extension points , well , hopefully something
can be done .

>> 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 B=
H
>> 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 :(
>
> Well, it is something to look into. API compatibility doesn't seem too
> difficult if we are able to detect the difference between the
> environments and others are willing to play along with the idea.
>

API compatibility on its own is not the main issue , considering the
fact that for components product-specific world will look exactly the
same as before . Semantically products are also exactly the same thing
. The main obstacle to succeed is database access. The fact that Trac
code base makes use of explicit SQL queries all the time is creating
such a problem due to the fact that current DB schema is not designed
for this particular purpose . If we only had a way to hide database
base access behind DAO [1]_ [2]_ [3[_ it would be much more easy to
override legacy environment-aware DAO and inject equivalent
product-aware DAO so as to make everything work in a magic , beautiful
way . Then we all would be happy, but no . The fact is that Trac-dev
has decided not to do so for a long time (do not ask me about the
reasons).

<joke>
Oh , mighty Java Beans !
I miss you so much . If you only were more ... Pythonic
</joke>

Maybe an option is to refactor Trac code base to introduce DAO (call
them models or not , using ORMs or not ...) before moving forward with
all this. Once that will be done then implement equivalent
product-aware DAO . Of course , in order to make all this work in a
way we can manage it'd be better if Trac-dev accepts the idea and
incorporates such changes into core.

.. [1] DAO =3D Data Access Object pattern
        (http://en.wikipedia.org/wiki/Data_access_object)

.. [2] Core J2EE Patterns - Data Access Object
        (http://www.oracle.com/technetwork/java/dataaccessobject-138824.htm=
l)

.. [3] DAO =3D Data Access Object pattern
        (http://www.roseindia.net/tutorial/java/jdbc/dataaccessobjectdesign=
pattern.html)

--=20
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: