PM>> Do the FTS specifications say that kludge lines can occur only before or

 PM>> after the message text? If not, then your assumtion is invalid. That's



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

 PE> not affecting any known implementations),



None that are know by *you*



 PE> then would you be happy to consider "kludge lines" to be "the

 PE> variable header information portion, which comes after the fixed

 PE> header portion, and before the message text", and thus be a neat way

 PE> of doing things, virtually identical to what you were proposing?



They would also need to remove the restrictions on what can go in the
message text. For example I should be able to enter a message with AREA in
the first column. I actually did this in my original reply to you but
golded kept swollowing it and I had to change it to MSGAREA. The same
applies to SEEN BYs, origin lines and tear lines. Why should I have to be
aware of these things when I'm entering a message?



What you're really proposing is to change the documentation to suite the
current inadeqate implementation, rather that properly designing and
implementing a new format.



 PM>> beside the point anyway. The fact remains that they are using a field

 PM>> for a purpose it wasn't designed for. This leads to all sorts of

 PM>> problems and generally makes life difficult for everyone.



 PE> They are using the "field" exactly like you were proposing!



No, the field is "message text" and they are storing control
information in it. This is the exact opposite of what I'm proposing.



 PM>> Squalid doesn't access the message base does it? I though it would only

 PM>> need to access the Squish configuration file.



 PE> Squalid does access the messagebase.  How do you think it read the

 PE> messages from you guys saying "add this area"?  Did you
think it managed

 PE> to intercept the Squish processing, or did you think it had a

 PE> mini-mailprocessor built-in, and I run it over my incoming arcmail

 PE> bundles before passing it to squish?



I thought it itelligent enought to just *know* what we all wanted. You mean
that it can't read my mind? Ok, I admit, I didn't think it through fully.



 PE> I think you misunderstood my intentions.  My intention was to isolate the

 PE> SQL as much as possible into one module.  Then I look at it (with my

 PE> eyes), and say "well, to open the cursor here, what I need to
do is do a

 PE> MsgOpenArea, which will work, because the index I am retrieving things on

 PE> consists of AREA and Arrival Date".  I basically just rewrite the whole

 PE> module, as though I'd never written it in SQL in the first place.  In

 PE> this scenario, there is little need to actually write it in SQL, but I

 PE> thought it was a good idea, because I can say it is portable, and also it

 PE> forces the interface to the SQL module to be standard.  No far16 pointers

 PE> either!!! BFN.



Aren't you going to write you're own SQL parser though that can read every
message base format under the sun?





Paul



--- GoldED/2 2.42.G1114