RJT> Things seem to be progressing nicely with the newer 
 RJT> multi-platform ports of Max and Squish,  and I hear 
 RJT> about nodelist compilers and other stuff that I'd need 
 RJT> here...

 RJT> There are a few other bits though,  that I'd *really* 
 RJT> like to have,  before I go ahead and port the whole 
 RJT> system over to linux:

 RJT> DLC -- this is what puts those download counts into 
 RJT> the files.bbs files.  It can initialize any given file 
 RJT> directory,  though I usually stick those brackets in 
 RJT> there by hand when I create the files.bbs,  and 
 RJT> updates them by reading the logs of both Max and Bink. 
 RJT>  I would imagine that it would be possible to do 
 RJT> something of this sort with some creative scripting,  
 RJT> maybe?

Source to DLC or a similar package (relased under a free type license, such
as GNU GPL or BSD, or artistic, etc.) would be nice.  I believe I could
code this up in a awk or perl script, but I don't intend to play such games
any time soon.  A recompile of DLC under Linux should just work.  If I
remember right DLC could read the Maximus control files and just work from
ther....

 RJT> PolyXArc and PktSort -- The former is a sort of a universal unpacker,  
 RJT> takes whatever archives are there and unpackes them to 
 RJT> give you *.PKT files.  I *think* that source for this was available,  
 RJT> might even have it,  I'd have to look.  The latter is 
 RJT> another story.  There were a couple of programs out 
 RJT> there to do this,  I have 'em both in my files 
 RJT> section,  but like PktSort better.  The big problem is 
 RJT> that it's an orphan.  Unregisterable.  What it does is 
 RJT> take a bunch of *.PKT files,  sorts them according to 
 RJT> what echos they're in,  and outputs one *big* *.PKT 
 RJT> file as output.  There are other things in there,  
 RJT> such as being able to split messages that are too big, 
 RJT>  and similar stuff that I don't care much about,  but 
 RJT> this *really* speeds up the tossing process for me.  
 RJT> If I had to move to linux and not have this,  I think 
 RJT> I'd miss it a lot...

I believe there is already a program out there to un-archive most archives,
which can be used to extract all *.PKT files for processing.  I believe
this replaces what PolyArc is used for.  Since I believe Squish looks at
the packet time stamps, and processes *.PKT files in proper date-time
order, this should be enough for what you were wanting....  But won't
provide all the spead up of the re-processed, single (new) *.PKT.  One
thing that PKTSRT did was re-ordered the new *.PKT file so that all the
echo mail was sorted by echoarea name (and within that by date / time
stamp).  This is why squish is significantly faster after using pktsrt --
because squish only has to open a given echo area's squish database files
once per run.  If you hold off processing packets (such as scheduled every
few hours), you can end up opening and closing a given echo's squish
database files multiple times.  Squish only keeps the most current three
echo area files open.  [So, if you get another message in an echo that was
four or more ago, you have to close up one of the open echo area squish
files and re-open that echo area's squish files....]  PktSrt I believe also
could break long messages up.  This has some uses (such as pacifing older
software, like a node under me uses).  [One of my downlinks will bounce
back (with new origin) echomail messages that are too long.....  [Please
don't deliberately do that, because it requires that sysop to manually
intervien to correct the problem....  And gives my dupe checker at 1:343/41
a workout which hides other problems while we work to clear up this type of
problem....]

 RJT> Any of you guys have ideas as to how something of this 
 RJT> sort could be implemented?

Yes.

Ok, so you wanted a longer answer....

Is the author of PktSrt willing to release source under a free type (i.e.
GNU GPL, BSD, Artistic, or other) license?  We might be able to get away
with a simple re-compile of PktSrt.  Based on what I've seen ported to
OS/2, I believe a program to replace PolyXArc exists.....  I'd have to look
up the name under OS/2 and then search for the Unix equivalent....

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01