Mon Sep 12 20:30:30 UTC 2005
> From: Georg Graf > > perhaps, but only if I added that source to the DCC source. > > I dont understand. regex.h on Linux is in > glibc-headers-2.3.2-95.33.rpm, on FreeBSD it's also in the libc. > Also on AIX there is regex in the system libc. I suppose on > solaris as well. which says little about old versions of those systems, not to mention AUX, the old System V varients, etc. It also says little about the real compatitility of POSIX regular expression libraries. POSIX standards are merely paper...and test suites with uncountable variations, ambiguities, bugs, and exceptions. > Not quite sure about Win32. It might be in some Microsoft DLL, but would you rely on Microsot's reading of a POSIX standard to be recognizable? Just now I read some of the hits from http://www.google.com/search?q=site:microsoft.com+"regular+expression"+posix and was *not* encouraged. Never mind that some of those hits sound like it would require the ".NET Framework." Maybe you would have no qualms about that, but I do. I don't think much of Microsoft software, but I must give them credit for paying real attention to upward compatilibity. That's something the Linux community seems to have no clue about, as demonstrated by incompatibilities among versions of rrdtool, wget, shells, etc > Why would you put > that into the dcc source? so that it is always there and fits with the calling code. MD5 might be a good example of how non-standard standard things are. I ship MD5 source because of incompatibilites in trivial "standard" MD5 libraries, as well as systems that don't have any MD5 library. > > you can't successfully ship an open source package that requires > > users to fetch, install, and maintain bits from other places. > > This would not be necessary, IMHO. Not for you, but there are probably far more than 40,000 DCC installations running on all kinds of more or less UNIX-like systems, including WIN32. When I'm writing code for my own use, I use all sorts of handy extensions, but when I'm trying to portable, I try not to use anything that wasn't almost universal 10 or 15 years ago. > > > I see the point that dccd would not be able to use regexes. do > > > dccm / dccproc / dccifd internally work on checksums? > > > > yes. > > What about exempting some whiteclnt options (e.g. ok regex > "bla-bla") and handling them differently? There are issues including storing and re-compiling the compiled regular expressions, error cases, and so forth. It would only be a SMOP (small matter of programming) to do something, but at the end I would have nothing that is not already available and far more mature in procmail, SpamAssassin, and other regular rexpression based filters. Instead of re-inventing other people's wheels, I think it is better to use their wheels. Judging from http://www.google.com/search?q=procmail+milter there are milters for procmail.
More information about the DCC