Hi Peter,
Thanks for bringing all these points up.
On 12/12/12 12:05, Peter Koželj wrote:
I am looking if I can help with this in some way. I admin I have
not followed this BEP too closely so I am doing some rereading.
Here are a couple of a bit late questions:
o Product routes
1. Is Trac's built in URL routing not powerful enough to accomplish this?
2. Can we do this in a way that leaves room to have product selection UI
elements that do not depend on URL's?
Product routing appears to be possible using the approach taken in
ProductModule.pre_process_request which basically checks for paths that
are considered to be products, then constructs a modified request in
order to discover the next appropriate handler for the request.
Clearly this does not have to rely on the url if other criteria can be
used to determine the match. The code in
ProductModule.pre_process_request matches the req.path_info using the
following regex at the moment: ^/products/(?P<pid>[^/]*)(?P<pathinfo>.*)
Perhaps the Routes framework would be better but it may require some
more justification.
o Database schema changes
1. Can we be exact with altered table list?
2. Something that we might forgot: What about 3rd party plugin tables that
reference multiproductized Trac tables?
Will probably need to proclaim these incompatible when more than one
product is in effect?
Good point. To keep track of records from tables from third party
plugins, this approach doesn't quite work. I would have thought that we
would be better off using a separate table to keep track of the
resources that belong to a product. Is this another area that has not
been updated based on discussions?
o Administration commands
This implies that we will have two different modes of operation (multi
product and single product) which will have to be chosen at
installation? Is this necessary? I can imagine users will start with single
product because it will be perceived simpler but will have additional work
to do when the need for second product arises.
I struggle to see a reason to support a deploy-multiproduct admin
command at the moment, partly because I don't see a reason to go beyond
providing a basic product path based namespace resolution. More on that
below..
o Product resources namespaces
I remember there have been some debates on this a few weeks ago and it
seems this sections does not reflect them or any consensus if there was one.
There may well not have been consensus so it is probably worth someone
attempting to review those discussions to see if there was much we could
agree on. However, I seem to remember that it ended with the suggestion
that webserver configuration should be able to sort out most url schemes
so we probably shouldn't worry about direct support.
Using a path based approach should be good enough for now and I would
suggest dropping others for consideration as a later enhancement - such
a later enhancement could just be a bit of documentation of course if
that is considered enough.
o Per product repository
Maybe many-to-many? There are all sorts of things out there in the wild.
But probably not common enough to warren phase 1.
Per product repositories does make good sense but it may be a good
simplification to avoid worrying about it too early. We should be able
to work with a set of globally defined repositories so we should make
sure that works first.
Cheers,
Gary
