An error checker would be handy. Especially for filters. I think I've found just about every which was to mis-spell endswith and startswith.
<<< [EMAIL PROTECTED] 7/12 7:33p >>> The XML file has one more advantage: A GUI could be created by Declude (which seems to be in our future anyway) that could easily configure Declude in a very structured way. This would simplify Declude configuration immensely! It could easily be done with a group policy looking editor. That should make all of the MS admins very happy. One other advantage is that Declude could include a config file checker that can parse the file and report any errors (like missing or duplicate info). This would be much more difficult on a flat file (probably why they haven't done it before now). As for the speed issue: IMO, the difference between the XML file and the flat file processing will be negligible with the relatively small file size. The disk cache will have the file in memory almost all of the time and the extra bytes required of the XML file will be offset by the faster parsing of the XML structure (parsing of regular expressions is very fast) provided by the MS XML object parser. MS has put a lot of effort into the efficiency of the XML object parser because they use it so often! Todd Holt Xidix Technologies, Inc Las Vegas, NV USA 702.319.4349 www.xidix.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee Sent: Monday, July 12, 2004 4:06 PM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [Declude.JunkMail] XML? Just Say "NO" ! Well we differ here on this point. XML is much more verbose and will explode the size of the config files probably 1000 fold Here is a sample Now SPFFAIL spf fail x 14 0 After XML - Possible Sample <Test name="SPFFAIL"> <Type>spf</TestType> <Action>fail</TestAction> <PlaceHolder>x</PlaceHolder> <FailedWeight>14</TriggerWeight> <NotFailedWeight>0</TriggerWeight> </Test> To parse the xml code for every load of declude.exe would take much more processing. This example takes the text lien and explodes it from 23 characters to 161 characters not to mention the added size to declude.exe to process the xml files. I do not think you have done much performace testing of XML in e loaded server environment. The loading of the config files from disk is minimal they should be cached due to the high frequecy of use. So 1 config file or 10 should not make much difference. Kevin Bilbee > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil > Sent: Monday, July 12, 2004 3:57 PM > To: Kevin Bilbee > Subject: Re[2]: [Declude.JunkMail] XML? Just Say "NO" ! > > > On Monday, July 12, 2004, 4:54:31 PM, Kevin wrote: > > KB> XML will definitly slow down the loading of Declude and I > know scott will > KB> not do that. XML will be a greate feature for the gateway > version though. > KB> Hint, Hint. > > I respectfully submit that this is not necessarily true. There is no > clear reason I can think of that an XML file configuration would need > to load any more slowly than the current configuration files. In fact, > I suspect that the structured nature of the file would most probably > improve the load speed if the parser were coded properly. This has > almost always been my experience when converting applications from > complex flat-file configs to xml configs. > > Consider also that it is likely an XML based configuration would > reduce the number of files required for a given system. - searching > for files takes time too. > > _M > > > > --- > [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the D --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
