On 29/09/2011 19:45, John Brendler wrote: > On Wed, 28 Sep 2011 17:40:20 +0200 > Mark van Dijk <m...@voidzero.net> wrote: > >> Hi, >> >> On Wed, 28 Sep 2011 07:07:23 -0700 >> Tom Eastep <teas...@shorewall.net> wrote: >> >>> I'm frankly not interested in having to document and support >>> different flavors of configuration representation. I would be >>> willing to include hooks in the compiler for doing the conversion >>> and for matching up filenames and line numbers in the error >>> messages to where an error or warning occurred in the original >>> source text, but I would prefer that these alternate configuration >>> formats be separate products that are documented, maintained and >>> supported by their creators. >> Actually, I'd like to go one step further and suggest to not bring >> this extra overhead into the project. It is a clear example of >> putting the cart in front of the horse. > I agree. Shorewall is easy to configure; all xml would do is make it > harder. If somebody thinks this is not the case, they need to learn > how to use an editor. GUI is an unnecessary additional layer of > abstraction, a potential source of errors, an expanded attack surface, > and a maintenance burden. >
You are missing the point that not all config files are written by humans... To highlight the point, consider the ratio of html websites written by humans vs database driven (or other cgi built sites). cgi generated sites dominate by a massive proportion. Personally I don't dig xml all that much, but sometimes it makes sense to store data in a particular format. eg many applications find either sql or ldap storage useful for common centralisation of configs. Others find json (or yaml) useful for integrating with web applications. XML has it's place also Note I'm not particularly trying to influence any direction of shorewall here. For the time being I'm planning to store my config in json and generate flat files via a simple "compiler". However, if this works out I will investigate deeper integration into shorewall. Digressing: Anyone who hasn't played with YAML should have a poke around the basics. eg Rails uses it for it's database config and a quick google search should turn up some examples of syntax. Notice that it's kind of "XML done better" and XML can be viewed as a complete subset of YAML. Of particular interest is the use of "references", ie you can define a bunch of attributes (a tempate) and then insert this reference anywhere else (this would be quite fun to have in shorewall). Personally I find YAML a similar overkill to XML and prefer JSON (which is technically a syntax compatible subset of YAML) for most purposes. Also the perl JSON parsers seem faster and more mature than the mammoth YAML parsers..? It seems fairly trivial to have a one way conversion from xml, json, yaml, etc to shorewall. I will try and contribute anything I produce, but perhaps others will contribute alternatives sooner. Also note that it should be reasonably easy to link such a "compiler" into the shorewall "make"-alike feature, so you could easily achieve a cascading effect where "rules.json" gets compiled to "rules" and then normal shorewall compiles that down as normal? This likely achieves most of what users currently desire? Good luck Ed W ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
