Text 313, 77 rader
Skriven 2005-03-30 18:43:09 av Russell Tiedt (5:7105/1)
     Kommentar till en text av Maurice Kinal
Ärende: don't cry for me I have vi
==================================
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 ... <g>

 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 <BEG> 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)