bbs-devel — BBS Development

[BBS-devel] Getting started again...and moving over to bbs-general.

[Michael M. <sho...@gr...>]

I recently graduated from high school, so I should have time to get this 
project up and running.  Is everyone still here?  (Terribly sorry about 
the long wait!)

I want to ease everyone over to bbs-general, and get rid of this list, 
to make management and communication easier.


Mike

[BBS-devel] Back on track

[Michael M. <sho...@gr...>]

School's been a real bear lately.

I want to handle the bbs architecture as a series of daemons.  Here's an
example:

  Rlogin
 /Telnet
|/ssh
|/serial/modem
|/other
* Input daemon (in *nix, this would be getty)
|
* User login ('login' in *nix)
|\User name/password Database(In *nix, this'd be Pluggable
Authentication Modules)
* BBS Kernel(In *nix, this would be the shell)
|\Text daemons (stdout of other apps.)
 \Other

[BBS-devel] Is this even working?

[Mike M. <sho...@ma...>]

Could someone post a reply, so I can at least be sure that my posts are at least reaching someone? :-/

Mike

[BBS-devel] Information

[Mike M. <sho...@ma...>]

I hate it when I do this...Whenever I think about something I'm doing, I completely re-do it.  Anyway, here's an outline detailing my thoughts on an effective means of dynamically dealing with linked lists, as well as my thoughts on the BBS, how it works, how it's used, and how it handles itself.




I LLists
  A Create
    1. List identifier(opt)
      a. randchar (PGP?)
      b. index
    2. Data structure
      a. 16 byte char array
        i. each byte designates the length of a field in bytes.
      b. Name(opt)
      c. Index (opt)
    3. Dimension structure
      a. 16 byte char array
        i. each byte designates the number of precreated cells for that dimension.
      b. name(opt)
      c. Index
  B Destroy
    1. Contamination Routine
    2.  Searchine routine
  C Modify
    1. Append
      a. (list identity or pointer)
      b. new cell's pointer.
      c. dimension index.
    2. (x)sert
      a. pre
        i. (list identity or pointer)
	ii. new cell's pointer
	iii. dimension index
      b. post
        i. (list identity or pointer)
	ii. new cell's pointer
	iii. dimension index
      c. de
        i. (list identity or pointer)
	ii. dimension-patch (2-char array)
  D Search
    1. Contamination Routine Clone
    2. Search Routine Clone.
    3. By data
      a. regexp
    4. By pointer
  E Load/Save
    a 'paging?'
II BBS
  A Users
    1. I/O Options
      a. terminal I/O
      b. C/S
      c. web
      d. (plugin?)
    2. User database
      a. shuck to OS. (works in NT, POSIX, most forms of Windows, and, I think, a few more OSs.)
      b. SQL
      c. +/- case-sensitive
      d. Data storage
        i. home directories
	ii. Mass database.
  B. Services
    1. Multiclient
      a. Daemon
      b. Cron job
    2. Isoclient
      a. spawn
      b. cron job
    3. IPC
      a. TCP/IP
      b. UDP
      c. SysV
      d. Samba IPC mount
      e. cron job


In (II)A1, different ways of interacting with users are listed.  There's the traditional serial/terminal IO, which effectively is simply a stream of data between the BBS and the user, whether it be over ssh, telnet, rlogin, a 33.6kbits/sec modem, or a null-modem cable.  'Client/Server', needs to be available such that you essentially can deal with what you're doing on the BBS in much the same multi-task way as how you deal with things under Linux, X, or the Windows GUI.  While not very effective, efficient, or good, web-based clients have become a 'given'...They're expected, and they're OS-independant.(Unless you consider browsers as OSs)  Finally, there are the thoughts of plugins.  I'm completely undecided as to how this should be implemented, but I feel certain that it will be necessary at one point or another, nontheless.

In (II)A2, different thoughts on tracking users are listed.  To deal with the user database, you might simply allow a Linux system to treat the users as, well, users.  This would simplify implementation on a Linux/UNIX/Posix system.  However nice it would be to do that, you run into problems if you need to transfer the user database to a BBS implementation on a different style of operating system.  While Windows NT allows specific users, M$ has a horrid habit of only allowing, say, 5 users to have accounts on the computer.  Windows 3.11+(3.11 was essentially the first step of normal Windows to a networked system...Windows 95 is the son of 3.11...Then comes 95a, 95b, 98, 98-sr1, 98-sr2, 98-se, and, finally, Windows Me. (Why in hell didn't they name it something else?  I'm sick of answering customer calls when the customer doesn't know if they have Windows 2000 or Windows Me.  All they know is that they have 'The new one.')) has an OK user system, except that its security is something to be laughed at.  My largest thought(and most coherent at this time of night) is directed at either SQL or Posix&Windows-Registry.
	In (II)A3, I noted case sensitivity.  A lot of people like it, a lot of people don't.  I suppose that means it'll have to be an option, since Microsoft's empire consists mostly of people who don't like case sensitivity.
	In (II)A4, I noted user data storage methods.  One way to do it is to use an SQL database, which again simplifies cross-platform issues.  The other way(and the one I like better) is to use users' home directories as storage sites.  Each system module could be given a '~/.xxxx' subdirectory where it can store pertinent data.
	In (II)B, I list service types, and how they're used.  'Multiclient' services are those that interact with more than one user at the same time.  For instance, chat-room environments.  The easiest way to deal with this are to use service daemons.  Cron jobs could be done, too, but would be somewhat more complex and wasteful.  'Isoclient' services are the equivalent of old-days' 'door' games.  If multiple people want to use the isoclient, the BBS just spawns mutliple copies...one for each one.  A good example might be vi, if you were to use it as an email-writer.  Isoclients are also possible as cron jobs, but have the same wasteful tendencies as multiclient cron jobs.
	In (II)C, I list forms of InterProcess Communication, or IPC.  TCP/IP is a simple method that would allow expansion of a single instance of a BBS package to spread over several computers.  UDP is simaler, but less reliable, as there is no gaurantee of data delivery.  Both TCP/IP and UDP have CPU and network overhead, though.  While I don't know much about SysV IPC, it seems to be the most efficient method available currently, and it's enabled on virtually every Linux machine.  As for Samba IPC mounts, I only know they exist.  I have no idea how they work, how well they work, or difficult they are to implement.  But I'm pretty sure that cron jobs are worse. :)

[BBS-devel] subscribe

[charlie y. <spi...@mi...>]

[BBS-devel] Pointer index

[Mike M. <sho...@gr...>]

I forgot to mention in the previous message that a list of pointers and
their cells' structure would be in operation.  I wrote some pseudocode
today to outline how I thought it would work:

resetpos(*looplist)
{
	for(;;)
	{
		if(looplist->ptr == \0)
		{
			return looplist;
			break;
		}
	*looplist = looplist->next;
	}
}

findcell(*cell_address, *looplist)
{
	resetpos(*looplist);
	for(;;)
	{
		*looplist=looplist->next;
		if((looplist->Node_address == \0) ||(looplist->ptr == cell_address))
		{
			return looplist;
			break;
		}
	}
}

append( pointer, structure, *looplist)
{
	resetpos();
	for(;;)
	{
		looplist=looplist->next;
		if(*looplist->next->ptr == \0) break;
	}
	ptr = malloc(PTR_SIZE + STRUCT_COUNT);
	cast (struct) ptr->next = looplist->next;
	cast (struct) ptr->ptr=pointer;
	cast (struct) ptr->structure = structure;
	*looplist->next=ptr;
}

presert(pointer, structure, *looplist)
{
	ptr = malloc(PTR_SIZE + STRUCT_COUNT);
	cast (struct) ptr->next = looplist->next;
	cast (struct) ptr->ptr=pointer;
	cast (struct) ptr->structure = structure;
	mv(-1);
	*looplist->next=ptr;
	mv(2, looplist);
}

postsert(pointer, structure, *looplist)
{
	ptr = malloc(PTR_SIZE + STRUCT_COUNT);
	cast (struct) ptr->next = looplist->next;
	cast (struct) ptr->ptr=pointer;
	cast (struct) ptr->structure = structure;
	*looplist->next=ptr;
}

mv(count, *looplist)
{
	if(count<0)
	{
		for(n++ until n==count)
		{
			cast (struct) data=looplist;
			for(;;)
			{
				if(data->next=looplist)
				{
					*looplist=data;
					break;
				}
				*data=*data->next;
			}
		}
	}
	elseif(count>0)
	{
		for(n++ until n==count)
		{
			looplist = looplist->next;
		}
	}
}

de_sert(*looplist)
{
	ptr=looplist
	ptr2=*looplist->next;
	mv(-1, looplist);
	looplist=ptr2;
	free(ptr);
}

find_ptr(pointer, *looplist)
{
	ptr=looplist;
	for(;;)
	{
		ptr=*ptr->next;
		if(pointer==ptr->pointer)
		{
			looplist=*ptr;
			break;
		}
		if(ptr==looplist) break;
	}
}

find_structure(structure, *looplist)
{
	ptr=looplist;
	for(;;)
	{
		ptr=*ptr->next;
		if(structure==*ptr->structure)
		{
			looplist=*ptr;
			break;
		}
		if(ptr==looplist) break;
	}
}


If my code seems haphazard and inexperienced, that's because it is...

Mike

[BBS-devel] Re: llist.c

[Mike M. <sho...@gr...>]

I didn't get the chance to clean it up...so I'll just post the code and
my comments in here.

> 
> /* NOTE: 'mbind' refers to causing two cells to point to each other.
>    English context is a verb, so 'mbind the two cells.'
>    NOTE: 'bind' refers to causing the first cell to point to the second,
>    but not cause the second to point to the first.  English context is
>    a verb, so 'bind the new cell to the described cell.'
>    NOTE: 'unbind' refers to causing the two cells to cease pointing at
>    each other, and instead point to \0, so that they go Nowhere.*/
> /* External-Function Code */

Three technical terms I coined to describe some of the functionality. 
"mbind", like it says, causes two cells to point to each other.  This
essentially means that the *next pointer of CELL_A is set to &CELL_B,
and the *prev pointer of CELL_B is set to &CELL_A.

"bind" performs the same as 'mbind', except that no action is taken on
CELL_B. So, 'binding' CELL_A to CELL_B simply sets the *next pointer of
CELL_A to CELL_B, but doesn't perform any action on CELL_B.

> char *ll_create(int dimension_count, dimention_descript
> *first_dimension_description, list_descript listdescription)

dimension_count is supposed to be a count of the dimensions involved
with the new linked-list.  These dimensions are referred to by an
index...if I have four dimensions, they are dimensions 0-3. 
'dimention_descript' describes the type of list that is represented on
that dimension--single or double.  I.E, can you transverse that
dimension forwards and backwards, or can you only transverse that
dimension forwards?  Also, it descibes if a given dimension is
looped(A->B->C->D->E->A->B->C...) and how many cells there should be
along that dimension initially.  'list_descript' describes two things
about the list: how many data variables there are, and what data type
each variable is.

> {
>         unsigned long int list_size=0, cell_size[2]=0, cell_count[3]=0,
> pointer_size=0, dimension_count[2]=0;
>         void* multiuse_pointer;

'list_size' is a variable that will eventually be equal to how much
space is necessary to place the new list in memory. 'cell_size' is a
variable that will eventually be equal to the size of a given cell in a
list.  'cell_count' will eventually describe how many cells are in the
new list at the time of its creation.  'pointer_size' is a variable
intended to contain how much memory a pointer occupies on a target
architecture.  'dimension_count' is for the purpose of building the
index.  'multiuse_pointer'...well, I don't remember. :(

>         /*Figure out the size needed to create the list.*/
>         pointer_size=sizeof(multiuse_pointer);
>         multiuse_pointer=first_dimension_description;
>         cell_size[0]=pointer_size;
>         cell_size[1]=pointer_size*2;
>	for(dimensions_counted=0;dimensions_counted=<dimension_count;dimensions_counted++)
>         {
>                 if (*multiuse_pointer->two_way<>0)
>                 {
> 
> cell_count[1]=cell_count[1]+*multiuse_pointer->length;
>                         dimension_count[1]++;
>                 };
>                 else
>                 {
> 
> cell_count[0]=cell_count[0]+*multiuse_pointer->length;
>                         dimension_count[0]++;
>                 };
> 
>                 multiuse_pointer++;
> };

I have something approaching \0 in terms of what I think I was trying to
do here..


The remainder (except where noted) of the code is essentially a
foundation...intended to guide the base structure.

> cell_count[2]=cell_count[0]+cell_count[1];

Although I don't remember what that line is doing there. (^^)

> char *ll_move(char *start, int dimension, int count)
> {
>     /*First, mbind the cells adjacent on specified dimensions.*/
> 
> 
>     /*Third, mbind the moving cell to its new neighbors on appropriate
> dimension.*/
> };

The reason I used type 'char' was so that pointer math could be used
when working with the linked list.  Not much I could do about it,
considering that there's no gaurantee on the structure of any given
linked-list.

> char *ll_insert(char *ends[2], int dimension, int count)
> {
>     /*First, create string of cells of appropriate type.*/
> 
>     /*Second, mbind one the lower end of the string to *end[0]
>       and the upper end of the string to *end[1]*/
> };
> void ll_remove(char *deadnodewalking)
> {
>     /*First, mbind the cells' neighbors*/
>     /*Second, kill the node.*/
> };
> void ll_destroy(char *start, int iterations)
> {
>     /*First, start iterations of self toward all of a
>       cell's neighbors that are not already tagged for
>       deletion.*/
>     /*Second, tag cell for deletion.*/
>     /*Third, if this was the last allowed iteration,
>       set remaining neighbors' pointers to \0.*/
> };
> char *ll_search(char *start, int field)
> {
>     /*First, check to see if 'start' contains the field data asked
> for.*/
>     /*Second, start iterations of self toward all of a cell's
> neighbors.*/
>     /*Third, tag cell as viewed.*/
> };
> char *ll_append(char *end, int dimension, char *cell)
> {
>     /*Run loops*/
> };

'*ll_append' mbinds(in the case of a doubly-linked dimension) or
binds(in the case of a singly-linked dimension) a cell to the cell
pointed to by '*end'...'dimension' is necessary so that the type of
dimension is known, as well as what dimension should the cell be
appended in.

> void ll_patch(char *deadnodewalking, char *dimension_array)
> {
>     /*First, patch *deadnodewalking's neighbors' pointers so they
>       either point to each other or point to NULL, as *dimension_array
>       requires.*/
>     /*Free *deadnodewalking*/
> };

Not sure what I was trying to do here.  All I know is that based on a
value in *dimension_array, each given node involving *deadnodewalking
either is reassigned to point to NULL, or bound/mbound with the cell on
the opposite side of *deadnodewalking.

> void ll_rip(char *deadnodewalking)
> {
>     /*First, set neighbors' pointers to NULL.*/
>     /*Second, free cell*/
> };

Same thing as 'patch', except that it's not patched, it's simply removed
with necessary pointers directed to NULL.

> void ll_dump(char *basenode)
> {
>     /*Unsure about file format...should resemble an outline.*/
> };
> void ll_load(char *basenode)
> {
>     /*Unsure about file format...should resemble an outline.*/
> };

'dump' saves the data in the linked-list to a file(or stream?), and
'load' performs the same action, in reverse.


I hope people start discussing this, most especially picking it apart
and fixing it.


Mike

[BBS-devel] llist.c

[Mike M. <sho...@gr...>]

I'm writing a summary explenation to the llist.c file in CVS...But I may
have to drastically change it from the current version in there just so
that the summary explenation makes any sense in the first place..

Mike

[BBS-devel] subscribe

[charlie y. <spi...@mi...>]

subscribe

[BBS-devel] Developer questions..

[Mike M. <sho...@ma...>]

I just thought I'd put in the most common questions people ask me before joining the project.


* Tell me more about what the actual project is.
The project's goal is to provide a decent piece of software, cross-platform, that performs the base functions necessary to a BBS.
* What plans have you got?
For the most part, it's a come-to-a-bridge/cross-a-bridge sequence of events.  I haven't been able to conjure up a decent set of plans from my brother's dark and mystical ISA bus yet..
* What's going to be the size of the team for the project ?
Well, I'm going to try to let the coder request in the SF "Job's Wanted" section expire on its own...And see how many people I've got then.  If the number grows too large to work efficiently, I'll have to mark the possition 'filled' or cancel the request.
* Do you have a URL with the details of the project?
Nope...not yet.
* What's the deadline for this project?
There really isn't a deadline.  AFAIK, there's no comprehensive piece of BBS software due for a release date any time within my life span..Time is a nonissue. :)
* Give me as many details as you can.
I hate running MS-DOS 3 on a P2-233 just so I can run a decent piece of BBS software.  It seems like a waste.
Other than that, I post thoughts to the -devel mailing list accessible at the SF website.


Last modified by Mike Mol(sho...@gr...)