capabilities of forthcoming group changes

[Joel Peshkin]

Jason Pyeron wrote:

>On Wed, 9 Jul 2003, Joel Peshkin wrote:
>  
>
>>I think that general sentiment is universal, but I should add the 
>>following constraints....
>>a) It must be possible to migrate from 2.16
>>b) The very first place to consider the efficiency implications is in 
>>Search.pm.  
>>
>>-Joel
>>    
>>
>
>Can you explain a? (Maybe my brain is fried this morning)
>  
>
Sure...

Many of the systems consideres in the group rewrite had to be discarded 
because they would have forced sites converting from 2.16 to have an 
explosion in the number of groups.  Essentially, we had to accept a 
requirment that a bug could require a user to be  member of multiple 
groups rather than a bug requiring that a user be a member of one of 
several groups.  There was quite a debate on the merits of "AND groups" 
versus "OR groups."  If you consider the implications of migrating a 
site that has bugs already in all sorts of combination groups from an 
AND system to an OR system, you will see the problem.  For every 
combination previosuly served by 2 groups, we would have to generate a 
new special combination group and the UI implications are really nasty.  

Personally, the only way I can see out of this quagmire would be to come 
up with a system that is clean for AND groups and OR groups 
simultaneously (an "AND-OR" system) but, as you point out, doing this 
efficiently is a challenge.

-Joel