Subj : don't cry for me I have vi To : Maurice Kinal From : Russell Tiedt Date : Wed Mar 30 2005 06:43 pm Hello Maurice. 30 Mar 05 06:56, you wrote to me: RT>> Formatting should be left to the reader/editor to perform, me RT>> thinks ... MK> Yes but in the interm a suitable crossformat is required. Very few MK> can handle the FTN formats. No problem, then they view all the kludges in all their glory tho they might not know what a fidonet address is to reply to. :-(( Come to think of it a set of "fido" macro's might be a feasable option fo VIM. RT>> And from my point of view, there is no real point in stripping RT>> the storage format for your msgbase down to the bare bones, when RT>> all PC's have more than sufficient hard drive space to handle the RT>> current formats, MK> Actually the real reason for a stripped down version has more to do MK> with conversions then it does to do with space, although that could be MK> a factor as well. To convert any messaage to any format a simplified MK> base messaging format would be the ideal methinks, and there is no MK> reason to convert and send anything that isn't related to either the MK> transportation of the messages or the message itself. I'm just wondering if the "ideal" is really that practical, seeing as you are going to need a database of some sort, to use as a msgbase, one may as well use the current JAM or SQUISH, and just add a few extra lines to the export filter to remove the not required bits, before adding the required bits, which are different for each format anyhow. Same difference is it not, if you strip them on arrival, or on departure, and at this point in time, I think stripping them on departure would be the easier of the 2 possiblities. RT>> If you want to cater for the emerging trend in Cellphone/handheld RT>> type devices, well fine, but even there they will start with RT>> compact flash card memory of one or other type that can be RT>> upgraded to the gigabyte region, there MK> That wasn't really my target but I suppose it could be. Again, it MK> isn't storage that is the issue, it is compatibility. Are we going MK> to rewrite utilities to cater to every whim or craze that comes down MK> the block, or exploit whatever those devices have at their disposal? MK> I vote for the latter. As above, I think it is a case of six of one and a half dozen of the other, either you change the utilities, or you change the database (msgbase), I think it is simpler to change the filters/utilities. MK> Right. Or just using a simple text based base(s) that are more MK> condusive to cgi scripting, which FTN or other "acceptable" Fido MK> formats aren't. Again, storage isn't the main issue other then the MK> structure of the storage and the simpler and compactness of the design MK> makes it more powerful when considering all sorts of targets for MK> display and useage of the messaging system, whatever it is including a MK> web based solution. Back to the "ideal" and do we change the utils or the msgbase. RT>> No it cannot, but, that doesn't matter much, till the last DOS RT>> user moves on or dies of old age. MK> Bully for them ... if they even exist. They aren't going anywhere and MK> is unlikely that any of what I am talking about will have any effect MK> they would even notice. They are obviously happy with all their MK> abandonware. Hmmm ... I have one, running a system here, and he is a paraplegic, just to make life "interesting". :-( Also no way I can tell him, "Sorry but I can no longer accomadate your system". It is what he has, can afford, and is familiar with. Russell --- GoldED+/LNX 1.1.5 * Origin: Rusty's BBS - Bloemfontein, Free State, South Africa (5:7105/1) .