Hi,
I have implemented a new group feature. So far we have group support with fixed matching: user X belongs to group G, etc.. This proves to be inefficient when you have huge block of users belonging to small numbers of groups. So I did some regular expression based groups: if user@domain matched a RE -> belongs to group G very usefull if try to provisions routing logic based on groups.
I developed this new functionality inside the group module since there is about same functionality and it's too small to be a separate module.
any pro or against comments / suggestions before committing?
regards, Bogdan
Bogdan-Andrei Iancu wrote:
Hi,
I have implemented a new group feature. So far we have group support with fixed matching: user X belongs to group G, etc.. This proves to be inefficient when you have huge block of users belonging to small numbers of groups. So I did some regular expression based groups: if user@domain matched a RE -> belongs to group G very usefull if try to provisions routing logic based on groups.
Very usefull? Great. no comments except a real world example would help for better understanding.
klaus
Hi Klaus,
imagine you have routing point between several termination points (gateways, media servers, application servers, etc) and you have large blocks of numbers/users (K or 10K order).
you know that certain range of users must be routed to specific destinations. You can do: 1) have a hard coded logic into the script, but it doesn't scale and is difficult to provision 2) use old fashion group, but you will end will huge DB. 3) use RE based groups to define the range of users -> flexible and scalable routing and simple to provision. BINGO :)
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Hi,
I have implemented a new group feature. So far we have group support with fixed matching: user X belongs to group G, etc.. This proves to be inefficient when you have huge block of users belonging to small numbers of groups. So I did some regular expression based groups: if user@domain matched a RE -> belongs to group G very usefull if try to provisions routing logic based on groups.
Very usefull? Great. no comments except a real world example would help for better understanding.
Sounds useful.
regards klaus
Bogdan-Andrei Iancu wrote:
Hi Klaus,
imagine you have routing point between several termination points (gateways, media servers, application servers, etc) and you have large blocks of numbers/users (K or 10K order).
you know that certain range of users must be routed to specific destinations. You can do:
- have a hard coded logic into the script, but it doesn't scale and
is difficult to provision 2) use old fashion group, but you will end will huge DB. 3) use RE based groups to define the range of users -> flexible and scalable routing and simple to provision. BINGO :)
regards, bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Hi,
I have implemented a new group feature. So far we have group support with fixed matching: user X belongs to group G, etc.. This proves to be inefficient when you have huge block of users belonging to small numbers of groups. So I did some regular expression based groups: if user@domain matched a RE -> belongs to group G very usefull if try to provisions routing logic based on groups.
Very usefull? Great. no comments except a real world example would help for better understanding.
-
Bogdan-Andrei Iancu -
Klaus Darilion