On 11/20/12 11:26 AM, Gary Martin wrote:
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:
[...]
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.
I think it should be enough to support one URL resource schema. If
someone has a wish to map this schema to something else I think that
should be, as Gary pointed out, possible by using URL rewrite approach.
[...]
Which resources do we have, that actually makes sense having outside the
project in multiproject setup?
If users are considered resources that would be one. Other than that,
maybe in the future we'd want to implement global permission schemes,
notification schemes, etc.
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.
+1
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.
+1 for tickets to always be associated with a product. During the
Bloodhound setup at least 'default' product should be configured.
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 :(
+1
Cheers,
Jure
