PE> It is a complete abortion not prefixing these with x'01',
PE> but it's too late now. I think the software should look
PE> for the last origin, but it would be helpful if there
PE> was an FTS spec detailing how you were meant to process FTS
PE> messages (e.g. what do you do if there are two INTL lines?).

BL> Yair. This is what I've been rabitting on about amateur standards
BL> and backup. Everyone (including me) makes it up as they go along.

Everyone doesnt, its mostly the amateurs who do. Often with very
clear evidence in the design that they dont even understand some
of the fundamentals of data structure design. The classic example
is having a format which is very fragile and which makes it very
hard to pick up the next valid message if there is a buggered one.

PE> The next problem occurs when there are dickheads who don't
PE> generate Origin lines, and there is potential for SEENBYs quoted
PE> by a user to get mixed up with the real seenbys, and no origin or
PE> tear to separate the two. The next problem is there is nothing in
PE> the FTS specs that says that the SEENBY lines will be consecutive!

BL> Yep. It's mad that the *first* packet generated does not have to have
BL> an Origin line. As for the consecutive SEENBY ambiguity, this is the
BL> sort of thing a standards committee picks up, but individuals miss out.

Thats crap too. You dont have to have a committee to get a robust
design, just someone who knows what they are doing designing it,
like any other design. In fact committees usually produce the most
fucked abortions ever seen. All the classic languages have NOT been
produced by a committee and the fucked ones usually have been.

BL> The only reason I can see to change the pkt format, is to let it
BL> handle graphics.

Just goes to show how limited your horizons are then Bob. Tunnel vision.

--- PQWK202