(Continued from previous message)

up badly designed electronic equipment just say 'too bad, you own
shit gear, your problem, not mine'. You cant to that with Fido mail,
they will tell YOU to take YOUR did messages and shove THEM, cos THEY
dont comply with FTSs. Thats the whole point of them, so they can.

BL> I would expect that Paul and you would take this tack, saying that
BL> some mailers read the mength of the Subject field, rather than
BL> making a mad assertion that the idea breaks Type2 Fido. It may not.

Thats only a small part of the problem. Even if you can get away
with putting crap on the end of the Subject field without it
breaking anything much, that wont give you graphics in the user
text. You would be far better off attempting a kludge which has
a byte skip field in fact and eliminate the possibility of breaking
the subject field processing code.

Still wont work anyway, and UUCODing is much better. It will and does.

BL> It is interesting to compare it to the 128-byte QWK fixed
BL> headers padded by spaces. When you zip QWK, it ends up smaller
BL> than a zipped PKT because the spaces compress to nothing.

RS> Thats mostly got nothing to do with the format of the header,
RS> its mostly just that quite a bit is dropped from the PKT to
RS> get the QWK, particularly the PATH and SEENBY stuff.

BL> No... I actually tested that. QWK has lots of consecutive
BL> spaces that compress almost as well as if they are deleted.

But so do lots of consecutive anything, nothing special about
spaces. The only thing you want to avoid is random crap coz the
archiver doesnt know its crap and will preserve crap perfectly.

Nothing to do with fixed headers. The Kludge line keywords
would normally be compressed by a dictionary compression too.

RS> Yes, you can indeed get weird effects. Someone proposed a binary
RS> format for nodelists for size reasons. Turns out that once you
RS> archive it its marginally BIGGER than the text one archived.

BL> ROFL!! Amateurs, Rod. Amateurs never bother to test; they think
BL> it can be done in their minds. Engineers have to work at it, or
BL> our bridges keep falling down and nothing works.

It was actually tested by other amateurs and discovered to be a dud idea |-)

BL> If we allowed a fixed 256-byte message header in PKT, padded
BL> by spaces, it would give tons for future change, and clear
BL> out the message field so that only message was in there.

RS> Yes, its a possible approach, but its far far too late for that now.

BL> Maybe not... if existing mailers accept it.

Nope, they cant. And even if some did, too bad, it flouts FTS,
thats the finish of the argument as far as they are concerned.

BL> If you create a new system, you'll end up with two running
BL> together for 20 years.

Nope, just get your feed cut.

RS> In fact the movement to a new standard from an existing
RS> one with no backward compat needs far far more than
RS> 'show a benefit' to get people to shift.

BL> Exactly. You see it with digital phones. A better system becomes
BL> stalled because manufacturers have already recovered costs for
BL> the linear phones, and can cut prices. A compatible system is
BL> much nicer, but it's not always possible.

And isnt in this case with graphics in user text the way you are
attempting it.

BL> If we base a new standard around graphics, then anyone using
BL> the ^a kludges in the massage field would be inmcompatible
BL> for graphics, but able to use text.

RS> Even thats not right. If you have for example a size field
RS> which is included in a ^A kludge line which precedes that
RS> block of graphics data, there is no limit on what you can
RS> have in that graphics block And its readily backward compat.

BL> The problem is that ^a could be part of the graphics,

Nope, you have missed the point completely here. You specify that
any block of graphics in user text has to be PRECEDED by that ^A
kludge line which specifys how much next to skip, the size of the
following graphics block. So you can have ^As in the graphics block
with impunity, coz you know from the byte count to skip over them.

The other way to handle them is to just double them in the graphics
block. Defining ^A^A as not a kludge line. Or more strictly a special
one which means 'a real ^A here please'

BL> and could appear in an inconvenient place (unless you exclude 0x01
BL> as part of the graphics). It would work if you could put the size
BL> field outside the message in a fixed-length header to identify it.

It doesnt have to be in a fixed length header at all, you are
comprehensively mangling together the question of fixed length
headers with allowing graphics text. ALL you have to do is include
the length of the graphics block in a kludge line BEFORE you come
to the graphics block. So you can suspend ^A detection for the skip
count block.

RS> A message reader which doesnt want to bother to display the
RS> graphics chunk can just skip over it. You can even use a format
RS> ID kludge to specify the format of whats in that graphics block.

BL> That could work - as long as you have a protected keyword like 0x01.

Yep, you managed to get a glimmer of an understanding by here.

BL> This is the way changes should be made... like colour TV.
BL> It doesn't take long before everyone upgrades.

RS> Thats crap Bob, software standards are nothing like that.
RS> You wont be getting the whole of Fido adopting your new
RS> mail standard just because you say 'hey you can include
RS> graphics in a message with this' It doesnt work like that.

BL> Rubbish! Microsoft has built their business on that principle.

And OS2 has been attempting that approach and it aint working Bob.

You only have to look at Hi ASCII and Fido to see how difficult
it can be, and THATs in the situation where the vast bulk of the
machines processing mail are PCs which dont have a problem with it.

BL> You offer something new, and 90% of the market upgrades
BL> whether they need it or not. Explain to me the advantages
BL> of Word 6, for instance...

And Fido mailers dont work like that. Its a completely different
market. With completely different behaviour. They STILL OTW hold
their nose and howl about QWK even. And you think THEY will just
leap on your graphics capability with glee ? Have I got news for
you Bob, and it aint good news neither |-)

They STILL use primitive linear text files for READMEs after all
this time.

BL> The hard part would be getting the new standard adopted,
BL> even if it were perfect. Writing the Colour TV standards

(Continued to next message)

--- PQWK202