Re: Bob needs a new catchphrase

From: paul c <toledobythesea_at_dbms.yuc>
Date: Tue, 31 Oct 2006 03:35:08 GMT
Message-ID: <Mvz1h.226612$5R2.204996_at_pd7urf3no>


Bob Badour wrote:
> paul c wrote:
>

>> BobTheDataBaseBoy wrote:
>> ...
>>
>>> To quote Allen Holub (a coder):  "Just say No to XML".  I will add, 
>>> in all its forms.
>>
>> The thing is, a bunch of people were asleep at the switch when the 
>> internet's growth underlined the need for better transfer formats, so 
>> as often happens the first attempt even though inferior prevailed.

>
> I respectfully suggest no new transfer formats were needed in the first
> place. To the ignorant, everything is a novel idea. Or perhaps better:
> those who ignore history are doomed to re-invent it.
> ...

For my own purposes, not necessarily the rest of the world's, I thought CVS was okay. I don't know enough to say whether similar would work for other languages, but maybe the more important question is whether it could ever be adapted (in a smart way) for non-text values.

I remember telling a customer that their fourteen message formats between different databases were more than they needed. They agreed that all they really needed was something like "insert", "delete" and "update" but it was too late to change since they had already finished their coding. Later they had to add messages to take care of events they hadn't thought of, in both systems of course. If they had just gone with three (or, better, two) kinds of messages, they would have had to change only one system (the recipient). It could just ignore the ones it didn't care about! Instead they required the sending system to know what the receiving system needed. This turned out to be an impossibility as anybody who has used airline cargo systems much can attest. I can envisage a system ending up with "fourteen" messages that   amounting to two original ones plus twelve "optimizations", but I could never understand the idea of upfront optimizations. I thought the purpose of economical design was to handle the optimizations that could be foreseen. Optimizations always cost money and the very term is quite a slack one in IT, if you ask me.

p Received on Tue Oct 31 2006 - 04:35:08 CET

Original text of this message