AWL>> If the user enters "AREA:" as his/her first line, and
AWL>> the software doesn't fix it, then too bad for the user.
RS>> Typical fucked abortion so common in amateur designed
RS>> protocols.
ac> If you don't fucking like the way the brain-fart-of-a-fucked-protocol
ac> works (and it does work), go fucking write your own bullshit damn
ac> protocol. And stop pissing other people off.
ac> Seriously, if you can't stand the heat, get out of the frypan.
ac> Cheers to Paul Edwards and others for getting off their butt and putting
ac> forward an idea or three, when all you can manage is complaints!
Actually, I think you've misunderstood Rod there. I happen to
agree with his sentiments. "too bad for the user" is a crime
against humanity. You should endeavour to develop robust
protocols. When a hole in a protocol is pointed out, you should
see if there is a way of plugging it, assuming it is too late
to abandon the protocol in the first place. I have identified
the hole, and have suggested SOT/EOT as a method of plugging it.
Alexander above was saying "who cares about holes", whereas Rod
has been saying that SOT/EOT is a good idea for plugging that
hole. And Rod hasn't been saying that he wants to write a new
protocol, he's been saying all along that if you're going to do
that, you should justify why you can't use X.400, since someone
has already spent a lot of effort doing just that. Which is
something I also agree with, why do we need 20 million different
Type-3 proposals when X.400 is available? I still reckon what
we need is for someone to create a Type-3 proposal based on a
subset of X.400 that isn't too difficult to implement.
BTW, when can I hope to see SOT/EOT being generated from your
system? :-) Actually, if Rod wasn't such a stick-in-the-mud
SOT/EOT would rapidly take off, because he would be generating
them with PQWK! Hey Rod, if I modify PQWK202 to add in the
*ONE* change (I'll show you the source code) to generate SOT/EOT,
will you switch to that? I'll call it PQWK202B. BFN. Paul.
@EOT:
--- Mksmsg
* Origin: none (3:711/934.9)
|