Wes Garland wrote in a message to All:

 WG> Okay, this message is addressed to all because I'm compacting
 WG> replies to about 75 different messages into one. Holy cow, I can't
 WG> believe the traffic on MUFFIN!

Ain't it great?  :-)

 WG> For all those who told me to use WordStar commands in MaxEd -- it's
 WG> been 10 years since I've used Maximus (actually, maybe 9 -- memory
 WG> is fuzzy) -- and it's definately been more than that since I've
 WG> used WordStar!

If you need to know what any of them are,  just ask me.  I used it *so*
much,  I think it's pretty well burned in...

 WG> Once Max is running stably on my platform, I think I'll pop emacs 
 WG> in as the "local editor". :)

I wouldn't mind something that was as simple to use as the dos qedit was, 
or maybe mcedit,  for a user editor,  though those are obviously unsuitable
due to the ability to get to a command prompt in at least the first case.



 WG> As long as curses doesn't get too snarky with me, I think I will 
 WG> try to make the local consoles pipes in the long term (right now, 
 WG> they wind up in the bit bucket). That presents the obvious problem 
 WG> of "what to do with the data backlog", however.. I could either 
 WG> tie the pipes to something that drain them regularly, or maybe 
 WG> trap SIGPIPE, have max drain its own pipe (if not being used by 
 WG> the sysop) and then call refresh(). The other option, I suppose, 
 WG> would be hacking at screen to try and tie each Maximus node to a 
 WG> screen pty.

Beats me,  I don't even follow all of that.  Suggestion:  Make it a toggle,
 OFF by default.

 WG> I've never looked at the screen source code in depth, however. 
 WG> [Background info: I implemented the OS-level video hardware calls 
 WG> with curses, so max thinks the curses stdscr is the real screen]

Sounds good to me,  based on what I've seen it do with other programs using
it.  The main use I have for local snoop mode is to see where users are
having trouble or not,  and I log on locally to see that things I'm going
are working the way that they're supposed to,  otherwise I don't bother
with it and use my message editor instead.



 WG> I suppose we could go through the code and disable the local 
 WG> console mode entirely based on command-line switches.. but that 
 WG> doesn't really strike me as a productive use of development 
 WG> resources.

Or make it a toggle,  responding to some sort of a signal.



 WG> but it's not like we're limited in terms of numbers of tcp/ip 
 WG> ports. I just run binkd on one port, and maximus on the other..

Is there any sort of standardization with regard to this?

 WG> Starting from a mailer attached to a serial port is another issue, 
 WG> however. This is obviously valuable.

Would be my first intended use,  here.



 WG>  - There's one more start mode which I intend to implement --
 WG> opening a tcp/ip connection, raw or telnet, to a terminal
 WG> concentrator which has an attached modem bank. I have seen code for
 WG> these which run local daemon to provide a pty for each modem, but
 WG> I've always found those to be more trouble than they're worth. Yes,
 WG> I have the facilities to test this. :)

That include the users?  :-)  It would be interesting to see that setup
with a nontrivial load on it...



 WG> Roy/Mark:
 WG>  - I'll be modifying the V)ersion message sometime soon to now show
 WG> Scott's old FTN address or his mom's snail mail address. :) I'm
 WG> also going to try and get in touch with Harvey shortly and see if 
 WG> he'll release some of his software open source (that areas.bbs 
 WG> makin' thing -- what was it called?)

The files list generator?  That was HLIST.  It doesn't make an areas.bbs, 
but it takes the ones I have,  which just list filenames, download counts, 
and descriptions,  and adds the file size that it finds and the timestamp, 
a handy thing.  And it does a very nice job of reformatting the text when
it does so.

The only thing I'd like is the ability to generate multiple lists.  I've
noticed that some other products out there have that feature,  you define
your lists however and it does the job in one run.  As I do it now,  I have
HLIST running multiple times (about 10 times altogether).

 WG>  - Yes, Harvey, Scott, Tony Summerfelt and I are all NET249 guys.
 WG> Not bad for a city of 100,000. :)  'course back then, I was writing
 WG> lame call-back verifiers and such... in pascal under DOS. LOL.





 WG> I think we're better off getting the current product stable before 
 WG> we start grafting stuff on.

Sounds like a *good* idea to me!  :-)



 WG> This could cause the serial port to get in a 'hung' state, 
 WG> however, if a user drops carrier.

Not good.  They ALL do here,  every single one of them,  in spite of the
fact that my oodbye commmand is on every menu in the setup...

 WG> If the modem supports &d3 (reset on DTR toggle), that will fix 
 WG> that, although not all modems do. (Heck, I'm not even sure all 
 WG> modems support &c -- I know you can override carrier with a 
 WG> dipswitch on USRs -- most of my work is with ZyXEL modem racks).

I have two here currently -- a USR Courier and a MaxTech.



 WG> I also have no intention of adding ftp/gopher/http/finger into 
 WG> Maximus, if people want to use that stuff, they should use the 
 WG> internet. A BBS should be a BBS, dammit. Doors *out* to the 
 WG> internet are fine, but making a BBS look like a mini-internet
 WG> always struck me as being totally counter-productive. :)

Some sort of a PPP login wouldn't necessarily be a bad thing,  though.

 WG> Mike and Bob:
 WG>  - Binary compatibility with previous release of Maximus and Squish
 WG> is  very important to me. The biggest issue that still needs to be
 WG> addressed there (besides debugging the squish bases -- thanks, bo!)
 WG> is the fact that some of the configuration utilites (MEX and SILT,
 WG> I think) still get upset over DOS-style newlines. I'm pretty sure I
 WG> fixed MECCA already, I seem to recall diffing a whole pile of *.BBS
 WG> files. MEX binaries may or may not be cross platform. I'd like them
 WG> to be, but pointer size issues may preclude compatibility on 
 WG> 64-bit architectures. Well, okay, *inconvenience* compatibility on
 WG> 64-bit arches. :)

MEX is something I never got much into using,  MECCA only somewhat,  and
SILT only because I had to if I wanted to get anything done.  Unix-approach
seems to be to have programs be able to parse text config files directly, 
and deal with it.  I don't know why all this other stuff was necessary, 
unless it was the earlier hardware/os platforms it ran on,  or something.



 WG> PS: Do I win the "long FTN message of the week" award?

Nah,  I think I got you beat,  elsewhere.    Though I could've
done so easily in here by simply quoting *all* of your post...

---