Christopher Lenz wrote:
Am 07.02.2006 um 09:38 schrieb Christian Boos:
On a related note, I was thinking about extending TRAC_ENV so that it
would
accept a _list_ of environment paths (e.g. envpath1:envpath2:envpath3).
That would make it possible for mod_python to handle environment in
multiple
unrelated paths, like tracd can do.
I don't like this whole direction that the InterTrac merge opened up:
making the Trac core aware of foreign environments. That was in fact
the main concern I had with the merge, but was unfortunately too busy
to give timely feedback.
Before InterTrac, the only parts of Trac that were aware of the
environment parent directory, or multiple environments, were the web
front-ends. And there, it should be considered a rather ugly temporary
hack that is only in place as long as we don't have multiple projects
per environment. So I really don't want to see the concept trickle
into the core.
I would even suggest that we back out the sibling auto-detection
feature. Accessing one trac instance now means that all "sibling"
environments also get opened, which is a considerable performance hit,
in particular for CGI, that you have to pay even if you don't need
InterTrac links. How much work is it really to just put the
environments in the global configuration file?
Why environments should be hidden from each other?
I see the sibling environment thing rather as a feature: the InterTrac
links to
objects from sibling environments are "richer":
* ticket links have descriptive title
* objects are marked as missing or not, as appropriate
For the performance, well, I don't think it makes sense to support
sibling environments
for CGI. I've actually never tested that for CGI, so I'm not sure that
CGI supports this.
I could disable that for CGI, sure.
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
