| |
SM0ORB > PSBBS 01.07.96 13:34l 165 Lines 7564 Bytes #-10328 (0) @ WW
BID : 7274_SK0MK
Read: DO3SMK UA6HJQ GUEST
Subj: Re: Public Source BBS
Path: DB0AAB<DB0MFG<DB0PV<DB0WGS<OE3XSR<OE3XZR<OK0PBX<SP6KBL<OK0PPR<OK0PKL<
DB0JES<DB0NHM<DB0SIF<DB0EAM<DB0HBS<DB0OQ<DB0HRO<OZ4BOX<OZ3BOD<SK6FV<
SK6YW<SM6KIK<SK6SA<SK6LK<SM7FEJ<SM7TYU<SK7AF<SM5SUH<SK5AS<SK5BN<SK5UM<
SK5AE<SK0MK
Sent: 960628/2114Z @:SK0MK.TELGE.AB.SWE.EU #:7274 [JO89TE] $:7274_SK0MK
From: SM0ORB@SK0MK.TELGE.AB.SWE.EU
To : PSBBS@WW
Hi Peter, Rolf and David
I like the idea of writing a BBS with public code according to
the GNU licence. I'm in, although my job takes up a lot of time
so i may not be the most productive participant.
Some comments on your writings:
:Rolf PE1PTP writes:
:First suggestion from my side is that it should be a non-TCP/IP BBS,
:because although it is a beautifull protocol, it is wrapped in another
:beautifull protocol (ax.25), this way creating much overhead.
I think a BBS should be built so it can support multiple protocols.
AX.25, TCP/IP and possibly future protocols should be easy to attach
in form of drivers. That way everything is possible to use.
:Peter SQ6BOT writes: (commenting Rolf)
:> - On what platform is it going to run ?
:
:PC. Which CPU? I think that it isn't good idea to write program working
:on 8086/80286-based computers. If anyone wants seriously to make a BBS,
:he takes at least 386 - many users, many disk operations is too much for
:poor little AT.
Agree !
But please let's make the code in such a way so it is easy to port
to unix and possibly other types of computers. Let's not forget that
the PowerPC chips have come. With some care in coding it should be
possible to make an easily portable program.
:> - How FBB-compatible must it look (and feel) ?
:
:From which side? User's or sysop's? For the very beginning on the users'
:side there should be just simple read, send and list command. Then we'll
:add more.
Thats only the beginnig, then comes, modes of operation, menu trees etc.
:From sysop's side it may look like FBB or not. Such interface requires
:much programmer's effort and has little effect to users (remember that
:BBS is for users, not for sysops). For the beginning sysop interface
:can contain one very simple channel for connecting (to BBS or through TNC),
:one for monitoring and one for 'sysoping'.
Preferably not too much like FBB.
I think you are right on separate channels for "local login" and
"management". I even would like the local login channel to go through
a virtual COM port so that it "really" is the same as for the users.
:> First suggestion from my side is that it should be a non-TCP/IP BBS,
:Yes, I agree. But I have one idea for the future: TCP/IP NNTP server, that
:has groups named 'ampr.bbs.<boardname>' (like ampr.bbs.all, ampr.bbs.pgp...)
:- like it's done on TCP/IP some servers in Germany. Such server could be
:build into regular AX.25 BBS. But this can wait for later time.
What about a BBS working with both TCP/IP and AX.25 ?
Mail coming from TCP/IP users/BBS's enters the AX.25 net at this point,
the TCP/IP station putting it in gets an R:-line identifying it as a
subordinate BBS.
Mail from the BBS net sent to a TCP/IP station gets a RFC style header
entry.
That way the originating system can always be identified as subordinate
to the own BBS and return mail is hopefully correctly routed.
:BBS should work as a TSR - to allow other (ex. node) programs. And should
:use as much EMS memory, as it is possible.
Hmmm.......
I don't think that will work other than on a very small BBS. Consider
disk operation together with communication, thats hard to do.
One more point is that using EMS is not easy, all kind of memory
swapping with a TSR program must be considered very dangerous.
I think it will be easier to make it a program wich runs under OS/2
then you have better memory management and can use built in functions
for multitasking. Note that all BBS programs for DOS have their own
multitasking kernel built in. This includes node software. And running
several program with multitasking kernels on one machine works poorly,
they tend to lock things up for each other.
:My proposals for basic skeleton:
: - TNC and TFPCX support,
: - channel for sysop for connecting through TNC, monitoring and sysoping
: - when someone connects to BBS, he gets prompt and enters command loop,
: - commands: read, send, list
Agree with the following additions:
- KISS mode support
- commands: delete, paging, abort, name
- all commands available at paging prompt
:It wouldn't have forwarding - first it has just to run, then we'll add the
:rest.
Right so.
:Rolf again (commenting Peter)
:>We also have to discuss way of storing messages on the disk to not make
:>searching too slow.
:Hashing table maybe?
Maybe a part to have replaceable ?
I think that on OS/2 systems ordinary file access would do fine, the
disk access is really great as compared to DOS or Windows.
:Rolf again (commenting Peter)
:>The will be config.h file like in JNOS - every sysop would be able
:>to compile its own BBS software - depending on his needs.
:
:Hm. That's what I dislike of Linux and JNOS systems, one needs a C compiler
:to just run the d* thing. Why not spread the sources, and a complete
:compiled version which is configurable by an install program or cfg file?
:It would support the use much more. This way a sysop doesn't have to be a
:C- "guru".
Please... No config.h
It's better to specify very clear interfaces to each part of the program
and have options in a config file to shut parts down or even replace
the code with code in another file. We do not need to build the program
as one big chunk of code in one file, the code could be separetad into
several files where each file holds one specific function. If anyone
wants to change a part he/she makes a replacement for one of the
files, or just adds another file. The user (sysop) should not have
to recompile the program to configure it.
:Peter wrote
:who wants to add something new? Please stay tuned and start up your
:C-compilers !
Well, i got the BC++ for OS/2 ver 1.5 (2.0 ordered), it seams we all
use Borlands stuff soofar.
But put your compilers a bit aside for a few days and let's discuss the
structure a bit. I know it's hard to keep the fingers away from code
generating but if there is no structure to start with there could be
serius problems a little later on.
I suggest a basic structure like this:
- BBS kernel : handles the databases and operations on mails
- Disk interface : handles all disk operations
- User interface : handles command interpretation
- Console I/O : handles the screen, keyboard and mouse
- Radio interface : handles TNC's, connects, timings, protocols
- Multitasking kernel : distributes CPU time to all other parts
A user reading a mail would be handled as this:
1. The Radio interface receives connect and initiates a new user stream
in the User interface.
2. The User interface receives a read command and sends a read request
to the BBS kernel
3. The BBS kernel contacts the Disk interface to open the mail file
and sends the data back to the User interface
4. The User interface sends the mail to the Radio interface with paging
according to the users settings
5. The Radio interface transmit the message with time sharing according
to the load on the channel
Each of theese basic structure blocks has to be further broken down
in substructures, and more important, the interfaces between theese
blocks have to be defined. I think some kind of "signalling" interface
is preferable as opposed to the usual "procedure call" interface. The
advantadge is that in a multitasking environment when you pass on a
signal you are free to do whatever is next in turn, if you do a procedure
call you are still processing that job even if it means waiting for
eg. a command.
Now you have a lot to comment :-)
/Anders SM0ORB @ SK0MK.TELGE.AB.SWE.EU
Read previous mail | Read next mail
| |
