On 20/11/12 09:24, Peter Koželj wrote:
On 19 November 2012 16:45, Olemis Lang <[email protected]> wrote:
On 11/19/12, Gary Martin <[email protected]> wrote:
On 19/11/12 07:04, Olemis Lang wrote:
[...]
On 11/19/12, Apache Bloodhound <[email protected]>
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>.
[...]
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
+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 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.
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.
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.
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 «rejected
ideas» 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.
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.
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 :(
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.
Cheers,
Gary
