Text 8702, 101 rader
Skriven 2006-12-19 18:30:00 av Ross Cassell
     Kommentar till en text av Maurice Kinal
Ärende: here again
==================
 REPLY: 1:140/13.1 4588708c
 MSGID: 1:123/456 458879c5
 CHRS: CP437 2
 TID: hpt/w32-mvcdll 1.4.0-sta 09-04-05
Hello Maurice!

19 Dec 06 22:34, you wrote to me:

 RC>> I presume you advocate a single text file for each message?

 MK> No but it would be handy if there was an unique delimiter to indicate
 MK> the end of each individual message within a mail archive.  At present
 MK> it is a null which reveals nothing since each message as well as both
 MK> the pkt and msg headers contain a whole mess of, few of which are
 MK> really needed since much of the info is 16-bit ints or a set number of
 MK> bytes.

But in a binary file, all the software needs is to get the number of records,
each message being a record, then wham bam seek that record..

There are utilities that can dump a message base to text file, not to mention
you can manually do so with your reader.

What are the features and benifits of using text files, other than grep, awk et
al?

 RC>> This is
 RC>> sort of like the original fido/opus message base, but even those
 RC>> files are binary in nature.

Also same format used for netmail attach mailers such as frontdoor/intermail.

 MK> Fine but the bottomline is that in order to communicate universally on
 MK> a network then it only makes sense to have an accepted standard for
 MK> networked transfers.  At present that is a real can of worms
 MK> especially considering the differing transport agents being employed
 MK> or planned to be employed coupled with the method of displaying or
 MK> transferring (offline messaging) to users on any particular node or
 MK> so-called BBS which varies greatly these days as to what defines a
 MK> true BBS.  Your newsgroup<->fido gateway is a good example.

I think my jamnntpd setup is a good answer for the end user/non-sysop type,
those who dont want to have to sift through the normal schtuff a BBS imposes,
not to mention keeping archivers and such on hand.

Those with a always on internet connection, can sit there and literally get
there messages online as instantly as you or I can using msged/golded accessing
a local message base.

The setup is simple to..

 RC>> The more messages there are in even that setup slows down
 RC>> scanning and tossing, like I said too much file i/o.

 MK> That is debatable.  Right now far too much of the input part is highly
 MK> questionable as to how much usefulness it is to any scanning and
 MK> tossing scheme.  For instance I wrote a Perl script that could
 MK> noticably outperform hpt wrt speed at packing messages even with all
 MK> the 'proper' kludges to call it a raw FTN pkt in play.  Unpacking is a
 MK> different can of worms which it shouldn't be but is.

Have you looked at or played with the perl hooks in hpt?

 RC>> If you look back, it was Wayne who brought his baggage in here,
 RC>> although I suspect he fat fingered his keyboard.

 MK> Whatever.  Doesn't matter methinks.

It matters as to your earlier claim..

Let me refresh your memory..

Wayne was using a BBS he could access by his choice either via telnet or http,
when a internet issue either between him and that BBS or a system issue at the
BBS itself cropped up, Wayne came in here and blamed me for interfering with
his access.

Sorry Maurice I dont control the internet.

The BBS in question runs under windows, maybe windows was discriminating
against Wayne for running linux, a Bill Gates conspiracy of sorts, you think?

 RC>>>> Except the version I wanted and looked for was 1.1, the version
 RC>>>> I got via deb is 1.1.

 MK>>> Okay.  You should be happy then.

 RC>> So using the deb was ok?

 MK> Sure.  Is that what your Windows users use?  ;-)

apt-get worked nicely.

==
Ross
Fidonet Feeds Or Fidonet In Your Newsreader! http://www.easternstar.info
Fidonet BBS: telnet://the-estar.com
Email: rcassell[at]gmail[dot]com
... You do not strengthen the weak by weakening the strong.
--- GoldED+/W32 1.1.5-30413
 * Origin: The Eastern Star - Spartanburg, SC USA (1:123/456)