incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: [BEP-0003] Misc questions
Date Wed, 12 Dec 2012 13:30:06 GMT
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

Mime
View raw message