From: Anh (Ly) Vuong [mailto:[EMAIL PROTECTED]]
> [EMAIL PROTECTED] wrote:
> > ...
> > I think Ray mentioned somehing about order, XML is like a
> table it's order
> > is it's rowsource/recno, so when you read a XML file the
> parser has to call
> > the $IPCHAINS or whatever subsequently for each rule
> defenition on the XML,
> > eliminating the order problem.
>
> The problem in XML is that there is no 'order' enforcing in the XML
> spec; thus with SAX the order might be different from the DOM
> interface;
> then the parsing becomes dependent to a particular API.
> Ofcourse one can
> put in the ID attribute for the element to provide order hints, but
> still that's not the strength of the XML.
DOM's order is the XML file order (and I think all parsers use this policy),
but the ID field is always a must, on every table, even in XML.
>
> I still wonder if there is a way to detect the invalid order, thus
> iliminate the order inside the XML.
>
> > I sugest we separate a firewall script (a real ipchains
> scrip) in different
> > categories. can anyone provide a good complicated example?
> My intentions are
> > not to provide a ipchains specific conf file, instead a
> learning base for
> > the evolution to netfilter or the old ipfwadm.
>
> Agreed.
> Separation of network descriptions and firewall rules is
> good. If we
> think in terms of services & network, can we specify the rules? For
> example: "I have an FTP service, on default port, on the DMZ network,
> and I would like to offer this service to both the public & private
> networks", can a utility generate that rule correctly?
>
and all that logic would be part of the client app, releasing the LEAF
parser to only one job of reading the XML and executing IPCHAINS.
and the reverse process.
> Thanks,
> Ly
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
