Ed, On Mon, 2011-10-03 at 14:04 +0100, Ed W wrote:
>
> Actually, can I suggest that you *don't* support too many formats
> here? I only intended to show that there are various options, but I
> really think after that you should limit shorewall to "fewer" formats?
> (reduces scope for bugs and misunderstandings)
The code that I've implemented should be pretty foolproof.
>
> > I notice that you used a comma after the first pair and
> > below you mention the possibility of adding a comma separator. That's
> > okay so long as we require that the comma be followed by whitespace.
> > Otherwise, the syntax is ambiguous in as much as comma is used
> > frequently as a separator in column values.
>
> Aha, see now you come to a format which I think is quite interesting
> in that give or take some syntax tweaking it's JSON. Hence my
> original email.
>
> Roughly the syntax maps to a perl hash or array. An element is
> surrounded by brackets, either { } for a perl hash, or [ ] for an
> array. The semicolon could easily be done away with here because it's
> quite clear when we drop into "web" format.
>
> If you don't see a problem with this style then I would recommend
> going all the way and eliminate any corner cases so that you can
> accept literal JSON format for the entire file? (The main thing I can
> think of is that the line needs to end with a comma, ie "{ ... },") ie
> it a file can be round tripped using:
>
> use JSON;
> #slurp
> local $/;
> open( my $fh, '<', '/etc/shorewall/rules' );
> $rules_json = <$fh>;
>
> # decode
> $rules = decode_json($rules_json);
>
> # encode again (just for kicks...)
> $rules_json = encode_json($rules);
>
>
> Obviously shorewall can't use the json parser this way because it has
> to support columnar format also, but I think the advantages for
> guis/editors is obvious if the file format can be completely round
> tripped this way?
>
> It's also cool in that at least some tools can then use off the shelf
> parsing tools, without needing to build a new config file reader?
If you want JSON so badly, then I suggest that *you* implement and
document a construct such as this:
BEGIN JSON
<JSON goes here>
END JSON
You already have examples in BEGIN PERL...END PERL and BEGIN SHELL...END
SHELL. That way, your configuration files can be pure JSON and noone
else will have to deal with JSON unless they want to.
> If I risked sticking my neck out again, personally for automated third
> party shorewall utilities (ie my hypothetical web based editor) I
> think the easiest formats to parse are the pure column format (ie
> existing) and the pure other config files above (key-value, perl, web,
> etc). Hybrids are the easiest to get wrong or make mistakes parsing
> and so less desired.
>
> As such whilst I don't have strong feelings over which format you
> finally stabilise on, I think desirable properties would be:
> - entire file can be column or..
> - entire file can be alternative style (as with your key-value)
> - ideally whole file can be parsed by off the shelf parsers from cpan
> or trivial code (true of column formats, key-value formats and many
> others)
>
> Note, I'm definitely not claiming your key value format doesn't fit
> those criteria, it does! Just highlighting that it's so very close to
> a couple of other formats it might be worth considering if one of
> those is a good/better alternative?
The formats that I have defined all fit on one line so there is no
requirement to match '{' and '}' over multiple lines. Any JSON produced
by a standard tool is unlikely to meet that requirement.
>
> > > 2) I don't know if there are currently any values which might contain
> > > spaces, however, it seems something that may happen in the future. I
> > > couldn't quickly see whether the current config file allows something
> > > like key="value with spaces", but is that something you might want to
> > > allow?
> > There are no instances of that and never will be. There really isn't a
> > lexical analyzer in the compiler; it rather simply uses "split(' ',
> > $line)" to isolate the individual columns. That precludes embedded
> > whitespace in column values.
>
> Oh, one last thing: This really sounds like the kind of feature you
> might require at some future point? OK, I'm struggling to figure out
> the what right now, but as you say it's because it wasn't possible
> before. Just some random ideas, but
> - what about allowing the logging text to be specified as as one of
> the key-value pairs?
> - Could some of the new "conditions" matches stuff need spaces?
> - I guess it will be any feature of iptables/tc which is expressed in
> ".." ? Are there many others right now?
>
> Just trying to think ahead!
I'm not loosing any sleep over that one; we've escaped for 10 years
without having to deal with that problem.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
