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 Wed, 21 Nov 2012 04:08:42 GMT
On 11/20/12, Gary Martin <> wrote:
> On 20/11/12 09:24, Peter Koželj wrote:
>> On 19 November 2012 16:45, Olemis Lang <> wrote:
>>> On 11/19/12, Gary Martin <> wrote:
>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>> [...]
>>>>> On 11/19/12, Apache Bloodhound <>
>>>> 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 «I do not see
a point for not having namespace configurable if that's what users
want» .

>>>> 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
>>>> specified as a subdomain instead.
>>> like in , 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 .

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

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

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 = Data Access Object pattern

.. [2] Core J2EE Patterns - Data Access Object

.. [3] DAO = Data Access Object pattern



Blog ES:
Blog EN:

Featured article:

View raw message