PE>>> No, the FTS specs do not say that, but if they did (simple doco

 PE>>> change, not affecting any known implementations),



 PM>> None that are know by *you*



 PE> Or you, or anyone else in this echo.



Sorry, I obviously missed the poll you took of all the echo participants.
For the record, no I don't know of any implementation that will be affected
but I'm not egotistical enough to assume that because I don't know of any
they don't exist.



 PM>> They would also need to remove the restrictions on what can go in the

 PM>> message text. For example I should be able to enter a message with AREA

 PM>> in the first column. I actually did this in my original reply to you but

 PM>> golded kept swollowing it and I had to change it to MSGAREA. The

 PM>> same applies to SEEN BYs, origin lines and tear lines. Why should I have

 PM>> to be aware of these things when I'm entering a message?



 PE> Well that's a Golded problem then.  There's nothing that says you're not

 PE> allowed to enter AREA: in the first line of your message, nor anything

 PE> saying you can't enter SEEN+BY in your next (I just did then, and I bet

 PE> you it gets through to you too).  And here's a tearline -+- and here's an

 PE> Origin line: + Origin: try the next one matey!



All you've proved it that the software we used can accept SEEN BYs and
origins in the text. It proves nothing about the rest of the world.



 PM>> What you're really proposing is to change the documentation to suite the

 PM>> current inadeqate implementation, rather that properly designing and

 PM>> implementing a new format.



 PE> The current implementations are adequate.  The documentation would just

 PE> make it clearly define "the message text starts after all
these "\x01"

 PE> fields, which are the "variable control information format proposed by

 PE> Paul Markham".



Except for the ones that occur after the message and the ones that don't
start with ^A of course.



This is just sticking more band aids on the system. While it may continue
to work (barely), you end up with all sorts of inconsistencies and special
cases.



 PM>> Aren't you going to write you're own SQL parser though that can read

 PM>> every message base format under the sun?



 PE> Not if I can help it.  In fact, I was thinking of scrapping Maximus so

 PE> that I didn't have to implement ANY of them, and just use the database.

 PE> I might under pressure be moved to do a manual changing of the SQL into

 PE> MSGAPI calls. BFN.



If your not going to use Maximus, why are you still planning on using msgapi?





Paul



--- GoldED/2 2.42.G1114