Bob Jones wrote in a message to Roy J. Tellason:

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

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

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

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

I don't think it needs to read anything but the log files.  And scripting
does seem to be a viable choice with this one...

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

 BJ> I believe there is already a program out there to un-archive most 
 BJ> archives, which can be used to extract all *.PKT files for 
 BJ> processing.  I believe this replaces what PolyArc is used for. 

Even if not,  I believe the source for this one is available.  The program
doesn't do the un-archiving itself,  just calls the appropriate other
program to do the job,  if I'm remembering right.

 BJ> Since I believe Squish looks at the packet time stamps, and 
 BJ> processes *.PKT files in proper date-time order, this should be
 BJ> enough for what you were wanting....  But won't provide all the
 BJ> spead up of the re-processed, single (new) *.PKT.  One thing that 
 BJ> PKTSRT did was re-ordered the new *.PKT file so that all the echo
 BJ> mail was sorted by echoarea name (and within that by date / time
 BJ> stamp).

Just so.  That was the important part.  

 BJ> This is why squish is significantly faster after using pktsrt -- 
 BJ> because squish only has to open a given echo area's squish 
 BJ> database files once per run.

Yep.

 BJ> If you hold off processing packets (such as scheduled every few 
 BJ> hours), you can end up opening and closing a given echo's squish 
 BJ> database files multiple times.

I process stuff when it comes in.  But that's only a few times a day.

 BJ> Squish only keeps the most current three echo area files open. 
 BJ> [So, if you get another message in an echo that was four or more
 BJ> ago, you have to close up one of the open echo area squish files
 BJ> and re-open that echo area's squish files....]

I wasn't aware of that,  but it makes sense.

 BJ> PktSrt I believe also could break long messages up.

It had that capability,  but I never used it here.

 BJ> This has some uses (such as pacifing older software, like a node 
 BJ> under me uses).  [One of my downlinks will bounce back (with new 
 BJ> origin) echomail messages that are too long.....  [Please don't 
 BJ> deliberately do that, because it requires that sysop to manually 
 BJ> intervien to correct the problem....  And gives my dupe checker at 
 BJ> 1:343/41 a workout which hides other problems while we work to 
 BJ> clear up this type of problem....]

I've seen the results of some software doing that,  all over a bunch of
echos.  It's not fun.

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

 BJ> Yes.

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

 BJ> Is the author of PktSrt willing to release source under a free type
 BJ> (i.e. GNU GPL, BSD, Artistic, or other) license?

I have no idea.  At one point I read that he couldn't be found,  and then
that he'd turned up somewhere but had no particular interest in supporting
the program or accepting any registrations,  which kind of leaves people
hanging. My copy puts two lines of stuff and one line of
"unregistered" notice in the log file each time it runs,  and I
even had a small batch file to take that stuff out.

 BJ> We might be able to get away with a simple re-compile of PktSrt.  
 BJ> Based on what I've seen ported to OS/2, I believe a program to 
 BJ> replace PolyXArc exists.....  I'd have to look up the name under 
 BJ> OS/2 and then search for the Unix equivalent....

Well,  once we get these and max/squish/bink get stable,  I'll be ready to
jump and be running all-linux here.

---