Hi all,

	I'm replying this message cause I fully desagree with the statement 
that m0n0 whould not evolve with new and very usefull things just cause 
people use it inside soekris or wrap boards.
	I personally use it in most cases within wrap boards, but I have some 
cases where I run mono inside Dual Xeon 2.8 - 4 Gb RAM. Why we can not 
have this stuff in m0n0, but disabled? if you choose to run m0n0 inside 
a SBC board, no problem, just keep this features disabled, but if you 
have machine power why not?
	the problem may be the U$3,00 plus to go from a 32MB CF to a 64MB? I 
don't think so. Or may have more RAM, but this is a real problem?
	I developed lots of stuff to m0n0 in the last 3 months, but I gave up 
to post here, cause the answer is allways the same: "Bullshit, m0n0 
isn't developed for this purpose". Among this things I have squid 
integration in 1.2b1, snort integration in 1.2b1, database support for 
logging purposes, an even the internationalization. All of them ( don't 
really think this ) too heavy for SBC boards, but not to the PC case.


Jean


Dinesh Nair wrote:
> On 29/09/2004 07:40 Mitch (WebCob) said the following:
> 
>>> In that situation, the user database Dinesh discussed is exactly
>>> what they need.
>>
>>
>> I prefer that idea... just think it has to be on par with comparable
>> services (user capacity wise) or else we lose users... As an individual,
> 
> 
> my concern with the capacity of the user db is that m0n0wall is usually 
> run on soekris boxes and those do not have the capacity which a full 
> fledged PC/server would. in addition, each of the username/password 
> pairs would need to be stored in config.xml which then has to be synced 
> with the CF card on _every_ change. this would mean that the webGUI 
> performance will start to suffer as the number of users in the builtin 
> db increases. i had initially suggested a max of 16 to address this 
> problem.
> 
> however, what i'll do now is to make this max number of users a 
> configurable parameter but m0n0wall users need to be warned that a large 
> number of users in the builtin db will affect webGUI performance 
> adversely. somehow, as a developer, i feel i have a responsibility to 
> not give users the tools they can shoot themselves in the foot with.
>