<br><br><div class="gmail_quote">On Thu, Aug 6, 2009 at 12:36 PM, Matt Jonkman <span dir="ltr"><<a href="mailto:jonkman@jonkmans.com">jonkman@jonkmans.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Nick Rogness wrote:<br>
> Maybe the question should be who is the intended user base in the short and long term? If it is just unix geeks like us, then XML is not the answer. Then again, snort is already built for unix geeks. Is the goal to just develop a snort++ or address a more broad audience??<br>
<br>
</div>We're not looking to make a snort++, but we do need to stay compatible<br>
in many ways. Config thankfully isn't one of them.<br>
<br>
As for the audience, Security folks I'd say. I don't think we're<br>
possibly ever going to make ids simple and user friendly enough for the<br>
average joe computer user to config one.<br>
<br>
We MAY be able to make it easy enough for the average IT guy (MCSE) to<br>
do it though. I think that'll come along with the web based config tool,<br>
or some very intelligent defaults.<br>
<br>
But I don't think we need to consider that now. Unix geeks and security<br>
people I think should be the target audience for the config language.<br>
The rest we'll get with teh web config tool in phase 2.</blockquote><div><br>It might make sense to consider the people who may work on a web configuration tool in phase 2. Any strict format that we can achieve with flex/bison, yaml or XML will be appreciated by the developer of a config tool. But yaml and XML will probably shine for such a person. They don't have to worry about grammar or a parser, tools will do that for them and they only need to work with the data. Plus generating a configuration file will also be trivial as yaml and XML parsers usually also come with an emitter.<br>
<br>In this resect, YAML might be a good middle-ground, despite the fact that it cares about whitespace. It'll provide an easily parsed config file for the tool writers out there due to the availability of YAML parsers, yet it is easily edited in a text editor - even easier if you use a YAML aware editor like emacs in yaml-mode.<br>
<br>Hmm, I had no intention of this sounding like a go yaml post, as I'm on the fence here still myself.<br><br>Jason<br></div></div>