[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. :)