On Sat 24 Feb 2007 18:39, Pawel Foremski wrote:
On Saturday 24 February 2007 15:47, Peter Nixon wrote:
On Fri 23 Feb 2007 20:37, Pawel Foremski wrote:
Main differences to the classic approach are: counters count back, they can be resetted for each user individually and each user is given two counters - one being periodically resetted by the module itself, and one which it can only decrease (a "prepaid" counter).
Can you provide a comparison of how its better than rlm_sqlcounter?
From what I can see so far:
* 50 lines of code less + better documentation on how it works + support for "prepaid" counters, e.g. a dialup user can buy additional transfer when he reaches the monthly limit before the reset time + rlm_sqlcounter uses xlat to access SQL database (I suppose that's slower; the code doesn't check for errors) + support for bigger counters (compare e.g. lines 507 of backcounter with 662 of sqlcounter) + can add a new VAP instead of denying access in case of reaching the limit + far more flexible - supports only per-user limits (ie. not configurable counter "key") - hardcoded queries - support for MySQL only
BTW, there seems to be a typo in line 551 of rlm_sqlcounter.c ;-P.
Sorry, but rlm_sqlcounter seems to me too complicated for further analysis. Specifically, handling resets is so weird I can't even compare it to backcounter, which stores reset time for each user individually.
The code has just been finished, so be sure to test it before using in production environments.
Would you like this code to go into cvs?
Sure, but please give me a few more days for testing. I'll inform you when I think it's ready for inclusion.
Do you plan to add/support different sql databases in future?
No, because I don't need it.
It's not critical that you do, we thank you for the code contribution either way but at some point someone will try to use postgresql or some other database (me for example :-) and someone will need to support it...
That's how open source works, don't it? Someone who needs some feature adds it ;-P
Same question applies to rlm_netvim_pools...
I don't plan to add support for other rdbms than MySQL (at least in near future) in it, either.
Regarding the additional attributes you define for the dictionary, you should register an Enterprise number for them, and then we can add them to your very own dictionary.asnet as a VSA. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc