| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | sot/eot |
RC> Oh, BTW, I also think SOT/EOT is irrelevant. Just look for the RC> last occurrence of "SEEN-BY", "^aPATH", " ! Origin: ", "---" in RC> that order, to find the end of text. You have made my day, Ro, but you can look forward to a loony attack by a killer Paul. RC> Good to see some "new blood" writing fidonet software. I came to programming late, and to my amazement I find that it is fun! Writing a qwk2pkt converter and back again is just a way to learn a few programming tricks the hard way. RC> Have you linked into NET_DEV yet? That would be a much better RC> place to hold your conversations. It's more fun stirring Paul, who is kinky for ISO-C. My goal is to get him to write something in Visual Basic - the stirrer's Mount Everest. RC> Most tossers would first check for an AREA: line before any RC> netmail kludges. It's not unknown for braindead software to put RC> ^aINTL or other netmail kludge lines into echomail, either. Aha! I'd better go back and make sure I can handle that, then. BL> Oddly, two bytes are allocated for attribute, but only one is BL> used. Perhaps the second one could be used for zones: 16 of BL> each. RC> One? Incorrect. The attribute is a 16 bit word, 2 bytes. Yair - Paul sorted me out on that one. My knowledge of binary arithmetic is only slightly better than a Grasshoopper's knowledge of quantum mechanics :-) BL> IMO, the main problem with PKT format is the message header. It BL> is lacking: BL> 1. A conference name or number RC> A number would certainly not work with PKTs Yair... I keep forgetting that QWK has control.dat. BL> 2. A way to show that the message is netmail RC> All fidonet traffic originally *was* netmail only. Echomail was RC> an afterthought. Oh, well... something to show that it's *not* netmail! :-) BL> 3. Zone address RC> So were zones BL> 4. Point address RC> So were points Aaarrrgh! This explains why they are missing. BL> It should be possible to add an 0x0d at byte 66 (say) in the BL> Subject field, and use the last 6 bytes for the extra data, BL> without having to invade the message field. This would make BL> more sense than adding SOT, and the other kludges. RC> What if the data in those 6 bytes contained a null? whoops! RC> See? There's no need to rub it in... :-) RC> Limiting an areatag to 8 bytes is ridiculous. Some of the RC> internet gated newsgroups have areatags of more than 40 RC> characters. How would you suggest that I could squash RC> "PHSC_POINT_SYSOP" into 8 characters and still make it RC> meaningful? Or "COMP.LANG.BASIC.VISUAL.ANNOUNCE"? The internet is not real to me. I have enough trouble with 1000 areas, let alone a million! I concede your point, though. RC> When FTS-1 was first defined, everything was sent uncompressed, RC> so packet size was an issue. These days it's irrelevant when RC> everything is compressed, so a fixed size header would be a RC> good idea, and practical to boot. Yes. Thank goodness. One point to me, at last. BL> Do you know if mailers check the length of the 72-byte Subject BL> field? Maybe we can bung it all in there... RC> They (correctly) check for a null, and will assume everything RC> after that is the user text. The next null terminates the RC> message. What if your extra 6 bytes of data has two or more RC> nulls? Bang. I told you not to keep rubbing it in! :-) If they don't check for length, we could sneak hundreds of extra bytes and just use ascii without nulls. The ^a kludge lines are ascii anyway. RC> Rather than extending type 2, just create a new type 3. RC> Everyone else is doing it. (grin) I went through the change from TV to colour and FM to stereo, and the way to get a new standard accepted is to make it backwardly compatible, with added features (like colour or stereo). The only thing we could offer fido is full graphics in the message... or perhaps make it easily internet compatible? If we could extend the subject header to make the overall header a fixed size, and put everything in the header, we could do this without breaking the existing mailers... But I was just playing a mind game with Paul. Regards, Bob ___ Blue Wave/QWK v2.12 @EOT: ---* Origin: Precision Nonsense, Sydney (3:711/934.12) SEEN-BY: 690/718 711/809 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™.