| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | echomail |
RS> The problem is that you barely even test changes, just release and pray. RS> It aint exactly a terrific idea to just use stuff released like that. PE> It gets live-tested by the first person to use it. RS> Soorree, that aint anything remotely like rigorous testing. PE> Yes it is, a week of testing by Frank was plenty of testing. Soorree, that aint anything like rigorous testing. He doesnt post much, he may well not have posted even a single netmail in that time, most of the time something that say causes a message to get flushed on a particular system wouldnt even be noticed that it had got flushed. He doesnt post much in international echoes either. Thats NOTHING like rigorous testing. PE> And if you don't like PQWK's testing level, USE A DIFFERENT PRODUCT. Or choose to not immediately upgrade to a new release because it hasnt been rigorously tested. Novel concept what ? PE> I said months ago that PQWK had a problem, which caused me problems, You specified that particular problem, with embedded origin lines. I dont produce messages with embedded origin lines. It makes considerable sense to wait and see if you have managed to produce a wart with the new release or not. The same applys with Binkley right now too. Some may well prefer to continue to use say 2.59 if they dont have any particular need for what is in 2.60, waiting to see if there are subtle blemishes in 2.60. It doesnt make the slightest sense for everyone to immediately start using 2.60 as soon as its available and hope for the best. Soorree, that aint anything remotely like rigorous testing. And it aint as if you are gods gift to programming either, you lack of rigorous testing produced a situation where Tobruk was producing messages which were less than absolutely immaculate as far as FTSs are concerned, and it doesnt make the slightest sense for systems upstream of you to be silently binning entire PKT which have a message like that in them. PE> and if you have so little regard for that that you couldn't give a PE> shit if you cause me problems, well I consider that to be malicious. You can consider it to be whatever you fucking like boy. If you dont have the mental horsepower to grasp that not everyone chooses to code and pray, thats your problem entirely. PE> I am recompiling Tobruk now, with that bit of code commented PE> out, to allow what appears to be "routed echomail". Then I will PE> recompile it back to normal. And then THAT IS IT. NO MORE. RS> That doesnt sound like a terribly practical approach, because its quite RS> feasible for other than PKTs generated by PQWK to have that problem. RS> In other words, even if the latest PQWK is used, you havent allowed for RS> some other point which doesnt even use PQWK at all doing that blemish. PE> No, it's only a problem with people who send me packets directly. RS> And they dont all happen to use PQWK do they ? PE> No, they don't. I wish no-one used PQWK. Pity that you will still have a problem if someone who uses other than PQWK produces a message which does not match your bizarre ideas on what its appropriate to bin the entire PKT for. Luckily for you, those upstream of you dont operate like that with blemishes in YOUR code, coz that makes no sense whatever. RS> And presumably you dont expect Tobruk to only ever get used by you either. PE> No, I don't. So it would make a lot more sense if Tobruk did something rather more intelligent than just bin entire PKTs which contain what you claim is a less than absolutely pristine message. PE> The problem is that the address of the sender is not PE> 711/934 but whatever crap was in an inserted origin line. RS> Yes, no argument that there is a problem with embedded origin lines. PE> Not really. Using PQWK260, you can send me PE> embedded origin lines, and I won't complain. Pity that the are other ways of generating PKTs which can be directly sent to a system which is running Tobruk. Particularly in the future when more than you run Tobruk. PE> Or using MSGED, you can send me embedded origin lines. There PE> may be other software that doesn't like embedded origin lines, There aint no maybe about it Paul, you do see those at times, something must be doing that. You can proclaim that it makes sense to just bin entire PKTs when they aint absolutely pristine in your eye, pity that that would have see ALL of the messages leaving your system binned by systems upstream of you if others had such silly ideas about what makes sense. PE> but it's basically in-spec as far as I'm concerned, PE> they have to fix their software if they don't like it. Arent you lucky that the systems upstream of you didnt operate like that with the PKTs YOUR code produced, just silently binning the entire PKT and not saying a word ? RS> How best to DEAL with them tho is another matter entirely tho. RS> You can for example make a case for nuking the * on one of those RS> embedded origin lines IN TOBRUK, when its tossing a packet from RS> people who send you packets directly. And THEN it catches those warts RS> even when something else is used to prepare the packets than PWQK too. PE> No, the problem is not the embedded origin line in the MSG in PE> the PKT I receive from you, the problem is in the address in the PE> fixed header portion of the MSG in the PKT I receive from you. Yes, you fucked up when you originally claimed that it was an embedded origin line. The same problem still arises with messages that contain a superfluous MSGID too tho, it doesnt make the slightest sense to just change PQWK and have Tobruk silently bin entire PKTs when it sees a blemish in a particular message. Because if everyone operated like that, YOUR entire message flow from YOUR system would have got binned when YOUR code was producing less than absolutely pristine messages TOO. PE> You are not using your own address in there. Soorree, we are talking about an embedded MSGID. Its mad for Tobruk to be using one thats between an SOT/EOT as the source of 'my address' So it doesnt make the slightest sense to be binning entire PKTs which contain a blemish like that. PE> That is because of a bug in PQWK250. Pity that other than PQWK250 can produce messages which are not absolutely pristine by YOUR silly ideas on what constitutes 'the specs' RS> THATS what robust software is all about. Recognising that in the real RS> world not all packets can be guaranteed to be absolutely pristine. PE> No, that's why it was caught and rejected. Pity that that would be hard to do if all systems upstream of you silently binned entire PKTs that left your system with a blemish in a message Paul. THATS nothing like what robust software is about. PE> I don't check that area very often, that's why Keith's was weeks PE> old before I found it. You were lucky, I was looking for problems PE> from Keith when I found yours, so there was only a few days delay. And you also have to question the sense in being so lax about checking too. And not for example having some notification of a problem rather than just silent binning and hoping for the best. Coz if those upstream of you did that with anything less than absolutely pristine, YOU would have had a considerable problem yourself. RS> In fact for a time Tobruk was producing some which werent itself. PE> *I* fixed problems in Tobruk as soon as they PE> were pointed out to me, or I saw them myself. Pity that your completely crackpot approach of silently binning any PKT which contained a less than absolutely immaculate message would have seen the ENTIRE output from your system silently binned Paul. Luckily for you, everyone else has rather more sense than that. PE> YOU have to do the same, either by stopping using PQWK250, or upgrading. Soorree, using software which hasnt been rigorously tested aint my idea of anything remotely like reliable mail, particularly when you really have no way of seeing what gets out into fido and the recipient chooses not to reply and when it never got them at all. I repeat, it doesnt make the slightest sense to be silently binning entire PKTs which contain a less than absolutely pristine message using your nutty ideas about 'the specs' What DOES make sense is to notify the person who has produced a message which is a problem, and if that problem has been addressed in a later version of the software that he is using THEN use that or that person can choose to use other methods of avoiding producing that blemish in a message. PE> I did the work to fix the problem, it's up to YOU to PE> choose one of the fixes available. It's not up to PE> you to choose to not care, and send me corrupt mail. Christ you really are a complete fuckwit Paul Edwards. No one is deliberately sending you messages they know cause problems. And then there is the completely separate question of whether it makes sense for Tobruk to behave more sensibly with less than absolutely pristine messages too. In the case of embedded MSGID which are between the SOT/EOT pair, it may well make more sense to take no specific action with that message at all. Which just happens to be what all the other mail tossers do with a message with that particular blemish in it. RS> It would have made no sense for system up stream of you RS> to be silently binning entire PKTs when a wart was seen. PE> It would be nice if the system upstream told me. Funny that. PE> The thing is, I already told you. No you didnt. You didnt say that the version of PQWK I was using would allow a MSGID between a SET/EOT pair and that that was wrong. In fact you had raved on for many messages about the value of the SOT/EOT being that it ALLOWED various stuff which would otherwise be considered to be information a tosser used to be recognised as being part of the body of the message, so the werent a problem. PE> It's your lack of doing something about it that pissed me off. Pity you had such a massive series of brain farts on that then. And you STILL are on the utterly LUDICROUS proposition that it makes the slightest sense to be silently binning entire PKT which contain a message which isnt absolutely pristine in your eyes judged by your completely loony ideas about what constitutes 'the specs'. Luckily for you, the systems upstream of you have a HELL of a lot more sense than to do that. @EOT: ---* Origin: afswlw rjfilepwq (3:711/934.2) SEEN-BY: 711/934 @PATH: 711/934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.