On 9/29/2011 01:33, Simon Hobson wrote: > Mark van Dijk wrote: > >> 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. A better idea is that someone who needs >> this would write up some separate program that can take whatever input, >> XML or otherwise, and can export it to what shorewall currently >> supports. > +1 >
I like the idea of drawing a nice clean line between the parser and the compiler, and documenting that interface well (perhaps something as simple as a generic object interface or array of arrays). THe vast majority of users will still be serviced by the default (and supported) flat file interface (and with the new fix, I'm quite content with it again!) but specific applications can now plug in whatever config backend suits their purpose. Great for embedded solutions, and all-in-ones, where the flexibility and power of shorewall is useful, but the interface currently in place is infeasible to interface with (like someone suggested using shorewall with a web interface). Benefits: Shorewall will now be able to be used in more places and for more purposes cons: Extra code to write (probably) and a new interface to document. Useful only for edge cases and integrated solutions I don't know how much work it would be though, and I'd rather see new features and and more bug fixes if it's a lot of work to implement. ------------------------------------------------------------------------------ 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
