On Fri, Jan 23, 2004 at 12:57:33PM +0100, Julian Mehnle wrote:
| To reiterate myself: It's easier to *write* a working SPF parser that it is
to even *learn* XML.
There are people out there who could not write a working (or even non-working)
SPF parser no matter how hard they might try. These are the people at the low
end of the programming rungs who end up in jobs writing "business logic". Back
in the 60's and 70's, we called the "COBOL jockeys" and they were actually very
smart people compared to what we have in the bottom layers of programming today.
They can manage to, with substantial effort, write some code to call XML parsers
to get some data "de-serialized" to work with it as an object. Now this is not
to say that all XML programmers, or all Java programmers, are at this bottom
level. Certainly the writers of the parsers must be very high end programmers.
And many applications level programmers are geniuses in their own field. But
what a lot of these programming tools, of which XML is one, have done is to let
in the "riff raff". These tools let "anyone" develop a business application in
minutes. The trouble is, it LETS _anyone_ screw up a business application in
minutes, too.
The people writing SPF parsers, as well as the people integrating SPF parsers in
MTAs, are all high end programmers. And I am glad they are. This is not where
we need to pawn "grunt work" off to someone who might mess it up. This needs to
be done exactly right, and exactly consistently, and thoroughly secure.
Back around January 1, 2000, and the days that followed, ALL the Y2K bugs I
found
were NOT in older programs. Better programmers had been writign Y2K ready code
for 20-30 years. Sadly, virtually all the programs that failed in one form or
another did so in rather recently written programs. And further, most of them
were in higher level languages in greater proportion that the programs
themselves.
The most common mistake I saw was formatting the date in Perl using string
substitution. The string "19" had the digit year appended. So in 2000 the
expressed year was "19100".
To me, XML is somewhat like Perl. I'm not saying all Perl programmers are bad,
not am I saying all XML programmers are bad. But these "advanced tools" do make
things easier enough to let many bad ones in.
Implementing an SPF parser in, or for, Perl, is not in itself bad. In fact that
is a very good thing to have. But that by no means forces everyone to use Perl
to be able to query and process SPF data. If I need, or prefer, to use some
other
language, I can.
A choice of XML is nothing like an option of Perl. I don't have to come
anywhere
near Perl to be able to do SPF; I prefer to do it in C. But if SPF uses XML as
a foundation, the my choices are between the XML bloat, or no SPF at all.
| Also, although I'm usually all for visionary ideas, I'm beginning to lose
| every remaining respect I still have for the engineering and design
| departments of Mystery Stakeholder. Who the hell needs DOM to access DNS
| records? This is just insane.
Their low end programmers do. It is insane because SPF isn't something for the
low end programmers to be doing.
| It's easier to *write* a working SPF parser than it is to even *learn* XML.
If you want, I'll write you some Perl regular expressions that validate the
current SPF syntax *in less than 10 lines*. Try to do that with SPF+XML.
Please don't. You'd be stooping down to their level. Instead, think the
design through carefully, and code it carefully. Do spend hours and maybe
even days on it. Polish it to a fine shine.
| See ASCII.
Fear XML replacing ASCII. I warn you, it could happen.
| Who needs XML books and seminars if one can just read one page of "SPF syntax
description" and then write pure ASCII?
And nothing precludes writing tools to manage SPF data in XML anyway. It
would just be translated to real SPF TXT strings on the way out from the
DNS server.
| What's really missing here is an objective consideration of the
*disadvantages* of using XML in DNS, plus an objective consideration of the
*advantages* of using a far simpler pure-ASCII syntax.
|
| As long as Mystery Stakeholder refuses to do these considerations (e.g. by
taking part in active discussions), I think it's no more use for me (or anyone
else here) arguing against their obviously inconsiderate arguments.
There _are_ some legitimate uses for XML. But I think the problem is that
corporate executives are much like a kid who just got a birthday present of
a box of 1000 stickers. Soon everything in the house has a sticker on it.
Certainly XML worked rather well for what it was intended for. But then
something crazy happened.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡