xbbs features as request

[Sue Peru Sr.]

First of all I wish to say that for a first program, Sandy has done an OK
job with his XBBS software.  This followup is not meant to be a stab in his
back or anything at all like that - just a view from the other side of
the fence.

+---- Sandy Zelkovitz writes in <203 at turnkey.TCC.COM> ----
| I have been requested by numerous uucp messages to give a small break down
| on the features within XBBS. Well here goes................
| 
|  2) Up to 99 different message bases

The messages are in a non-standard format with all messages stuffed into
one huge file.  The messages are limited to a compile time maximum length.

| 16) Message of the day (pre-selected)

This is a hardcoded filename (the date) whose contents get printed out.

| 18) The following file protocols are available for downloading:
|     sliding windows/standard kermit, zmodem, ymodem, batch-ymodem, crc-xmodem,
|     checksum-xmodem, ascii, SEAlink, and type.
| 19) The following file protocols are available for uploading:
|     (Same as downloading except for "type")

All the file transfer protocols are external programs - you must have them
on your system to be able to use them.

| 20) List the contents of an archive file ( .arc, .tar, or .tar.Z )

This requires that you have a working copy of ARC on your system...

| 21) File directory summary

Simply a "ls -l directory > file ; cat file > modemport ; rm file" sequence

| 22) List all, new, or matched files

See 21 with a few additions

| 40) 100% "C" code using SysV termio

But not all of the code is supplied - you must find your own source for kermit,
arc, ...... (see above)

| P.S.  The full source code can be retrived from my system (750K uncompressed)

Before you rush out and download it, be warned:

	1) The code is *VERY* unstructured.  It looks as if the code was
	   written over a long period of time without any thought to 
	   combining similar features - there are several places where
	   the code prints out the contents of a file (Message areas, 
	   file areas, ...) and the routines are bulk copies of each other
	   with one or two quoted strings changed.  Even the (wrong) comments
	   are the same!
	
	2) The code makes extensive use of the system() call to do even
	   the easiest of things.  The code is quite slow when it comes to
	   these sections!
	
	3) The message base, file handling, and bulletins (motd and others)
	   use non-standard layouts and fixed length record formats.

	4) The code consists of one HUGE source file (107K) and about a
	   dozen small (< 5K) additions.  Many of the parts share the
	   same comments - indicating that they all began life as the
	   same source file - (e.g., many claim to be "file area" listers
	   in the comments, even though the code prints out things like
	   "Message Areas".)

If you are interested in doing a lot of work, his code isn't too bad
a starting place, but instead of hawking its new features he should
be cleaning up what he has.  This code is definitely not "comp.sources.unix"
quality - it just squeaks by as being something that comp.sources.misc would
appreciate.  (Sorry Brandon... :-)

I tried to talk to Sandy about this stuff (voice, my dime) and he implied
that he wasn't interested in anything I had to say.  So be warned that things
don't look like they will get any better in the future...

    -John

-- 
Comp.Unix.Microport is now unmoderated!  Use at your own risk :-)