sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (05/17/88)
I have been requested by numerous uucp messages to give a small break down
on the features within XBBS. Well here goes................
1) Up to 99 different bulletins
2) Up to 99 different message bases
3) Up to 99 different file bases
4) Addtional feature section where the system administrator can select up to
99 different external programs for the users to run. The selected programs
can optionally be run interactively or non-interactively.
( Used by many as the USENET link)
5) Up to 99 different selected files to read
6) A humor section
7) "Zip" mail section
8) A conference section
(Similar to CompuServe )
9) On line chat capability
10) On line help
11) System administrator designed questionnaire using the questionnaire
language.
12) Passwords
13) Command privileges
14) Adjustable usage time
15) Adjustable upload/download daily "byte" limits
16) Message of the day (pre-selected)
17) Shell escape ( like other commands, this too has a privilege level assigned)
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")
20) List the contents of an archive file ( .arc, .tar, or .tar.Z )
21) File directory summary
22) List all, new, or matched files
23) Each message base contains its own user log for rapid "new" message
information.
24) Indexed messages for rapid retreval and insertion.
25) Automatic enable of message deletion.
26) Private messages
27) Message reply
28) Message scan ( 2 different ones )
29) Read messages in either forward or reverse direction
30) Read only the messages that are for you
31) Select individual message
32) Message base summary ( by you, from you, and new to read )
33) Daily accounting log
34) Usage log
35) Online monitoring ( you see what the user sees ) if enabled
36) Forced chatting
37) File/record locking
38) Signal controlled
39) Alarms --- three different ones
a) login time limit
b) usage limit
c) response limit
40) 100% "C" code using SysV termio
Needless to say, there are MANY more features; however, I think that I mentioned
the main ones.
The following features will be in the next release:
1) Multiple directory file find
2) Request another user to go into CB with an ongoing conference.
I hope that the above information is of help.
Sandy ( 714-898-8634)
P.S. The full source code can be retrived from my system (750K uncompressed)
.......!ihnp4!hermix!alphacm!sandy
.......!trwrb!ucla-an!alphacm!sandy
.......!uunet!turnkey!alphacm!sandy
.......!ucbvax!ucivax!icnvax!alphacm!sandyroot@uwspan.UUCP (Sue Peru Sr.) (05/22/88)
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@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 :-)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/24/88)
A few comments on a recent response: In article <3837@uwspan.UUCP> root@uwspan.UUCP (Sue Peru Sr.) writes: | 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. | | 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. True, but the sources are all available on alphacm. I certainly agree that not bundling the transfer sources is a good idea, why retransfer what you already have. | | 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) 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 | ... comments deleted ... The program structure is awful. No other word will do. | 3) The message base, file handling, and bulletins (motd and others) | use non-standard layouts and fixed length record formats. Sad, but true. I have given up on adding messages from files on the system. I just put them in as downloadable files. | 4) The code consists of one HUGE source file (107K) and about a | dozen small (< 5K) additions. Many of the parts share the I agree with all of the bad things about the program structure. | 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... When I first got XBBS I fixed a number of bugs, and made a major enhancement to the questionare software. I sent all of this to Sandy, and heard nothing. I recently sent a msg asking if he had the stuff, directly to his system via uucp. Nothing. He doesn't seem to care what changes people make, but he isn't tracking fixes or suggestions. I have no problem with this, this is his software, and he is offering it to the public to use as a service, but I haven't gone to later versions, because it's too much trouble to make them work. I will add that I exchanged mail with Brandon about fixes and enhancements to UNaXcess, and got the same response, BUT I got a pleasant reply saying something like 'thanks for the interest, but I'm moving in another direction.' He did post a fix for a problem a number of us had with the original package. Most of the really good programs on the net seem to be the product of one person, or at least in the control of one person. Some are more interested than others in user input. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
allbery@ncoast.UUCP (Brandon S. Allbery) (06/01/88)
As quoted from <3837@uwspan.UUCP> by root@uwspan.UUCP (Sue Peru Sr.): +--------------- | | 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... +--------------- If arc, tar, kermit, Xmodem, SeaLINK, zoo, Zmodem, CIS B, etc. were all bundled into a single XBBS (or, for that matter, UNaXcess) binary, you would end up with a singleuser Unix/Xenix system. DOS gets away with it because it's only one process anyway. But most people who run Unix/Xenix BBSes would like to use the multiuser capabilities of *nix -- and humongous, monolithic programs don't allow that. (Okay, you can use a paging 386 system. So now it's multiuser molasses.) Also: what if Arc were compiled into XBBS and some sysop wanted to support Zoo archives? Hmmm? External programs can be announced to the BBS via ASCII control files: edit and voila! New feature added WITHOUT recompiling. It's a design decision. Some of us prefer flexibility. +--------------- | | 21) File directory summary | | Simply a "ls -l directory > file ; cat file > modemport ; rm file" sequence +--------------- Can you say "portable"? BSD has portable directory routines. System V does, too: but calls them by a different name. EARLY System V and previous AT&T releases (and Xenix 2/3, etc.) don't have them at all. UNaXcess will break when used under V.5 with a non-AT&T filesystem -- which may yet happen, courtesy the file system switch. I hate to say this, AT&T: but "struct direNt" was a DUMB idea. Incompatibility still reigns supreme. AAAAARGH!!!!! -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery Delphi: ALLBERY MCI Mail: BALLBERY
guy@gorodish.Sun.COM (Guy Harris) (06/01/88)
> Can you say "portable"? BSD has portable directory routines. System V does, > too: but calls them by a different name. EARLY System V and previous AT&T > releases (and Xenix 2/3, etc.) don't have them at all. Yes, but they can be provided; the source to the 4.1BSD version was posted to the net about 100 years ago by Kirk McKusick, and other versions are in the "comp.sources.unix" archives. > I hate to say this, AT&T: but "struct direNt" was a DUMB idea. > Incompatibility still reigns supreme. AAAAARGH!!!!! 1) I don't think this was AT&T's idea, I think it was POSIX's. 2) It's not such a dumb idea if you have to include <sys/dir.h> on a V7-filesystem version of UNIX (which defines "struct direct" as the 16-byte format directory entry) in your program. The only reason it was done was to avoid namespace collisions.
ford@elgar.UUCP (Mike "Ford" Ditto) (06/06/88)
In article <7841@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: > Can you say "portable"? BSD has portable directory routines. An utterly ridiculous statement. > I hate to say this, AT&T: but "struct direNt" was a DUMB idea. > Incompatibility still reigns supreme. AAAAARGH!!!!! What would you suggest, that they return (struct direct)s so that BSD code will compile but not work? Do like BSD does and prohibit programs from using (struct dirent) and (struct dirent) in the same source file by giving them the same name? What they did instead was make a system that, unlike BSD's directory(3C) library, is *portable*. 1) it separates "portable" directory reading from BSD-style implementation-dependent direct filesystem access. 2) it works on various filesystem types, even on the same system. 3) it can be used on SysV or BSD, unlike BSD's equivalent. 4) it can be made compatible with typical BSD code that believes it is reading (struct direct)s from the directory by simply doing #define direct dirent. 5) it takes a few keystrokes to convert a BSD program to use the better (struct dirent) interface. A few more keystrokes will make it also compatible with the old BSD directory routines. The original BSD routines were never meant to be "portable", otherwise they wouldn't have returned pointers to internal filesystem data types and required user programs to know the format of these data. But you know you'd get flamed for a statement like that, didn't you? :-) :-) :-) :-) :-) :-) :-) :-) :-) -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads