Notes for Halidel, the new Citadel/UX Backend

Brainstormed feature ideas

• Cross Posting between rooms
  • .Enter Crosspost vs. CR CR Crosspost (Both?)
  • Hardlink the file from one room to the other
• Web UI (Rusty)
• User settable "Default" room.
• Aide SU Command. Allow an Aide to Zap rooms, but SU into full priv mode.
• Decaying traceability of anonymous posts
• Persistant logging of messages, archiving of discussions.
• A decent text editor
• .Read Last [x] posts

Bugs to fix

• Room Name Length
• Different screen widths for entering a message and displaying a message.
• Cryptographic password storage
• Messages Remaining after replying in Mail> from a <R>everse Read

Plan

1. Phase 1: Replace the existing backend with our code.
   • No new functionality
   • Many features removed, eg:
     • Networking
     • Files
     • Floors
   • Use existing Protocol and Client, unmodified.
   • Build new backend file-store.
2. Phase 2: Start adding features, Client bug fixes
   • Quantifiable and documented modifications to the protocol.
   • Add each feature to the client and backend at the same time.
   • Changes to client for UI "issues" (Ref: any post with the word "CitaCrap" in it)
3. Phase 3: Potential total re-write
   • If deemed necessary, a total re-write of the client and/or protocol may be necessary.
   • This Phase will be detailed out if necessary.

TCP Protocol

This is our new version of the protocol. We've taken that file and pulled out the commands we have no intention to impliment (eg: anything dealing with floors, files or Citadel network connections.)

In addition, each protocol command has a state or group of states from which it is appropriate to issue that command. The state diagram can be found at the top of the file.

Data Store Layout

All the data used by the BBS will be stored in, and in subdirectories of, the data/ directory in the BBS user's home directory. All files are owned by and readable only by the BBS user.

All BBS-wide information is stored directly in data/ . Eg: The configuration file, and any system-wide state information such as the file containing the next available message number, next available user number, etc.

All user information is stored in data/users/ . Each user has their own directory which contains all the information for that user, such as their username, password, registration information, RoomNumber:LastRead pairs, etc. User directories are stored in user number formats to allow for usernames to contain non-directory-happy characters.

Start Raj's Prattling here
Examples of possible file structures:

Global user file:

username:password:usernumber:homedir

This can be a little more free-form, I'd say, and could probably be \n delimited

screenname
address
city
state
phone
shoe size
etc.

End Raj's Prattling Here

Begin Mark's Rebuttle Here

I don't really see a reason to have a global user file. It's more data to have to keep track of and make sure doesn't get disjoint from the individual files. The list of info can just as easily be gotten to by itterating through all the files in a directory, which with appropriate use of library or method calls, isn't any more difficult than itterating through a file and tokenizing a line.

Your suggestion for each individual file looks fine. I'm going to flesh that out more as I write code.

End Mark's Rebuttle Here

Each room has its own directory in data/rooms/ . In each room directory, there is all information pertaining to that room (eg: the configuration of that room, the Room Info file, etc.), as well as a file for each message in that room. The exception to this is the Mail> room. Each user has their own Mail> room in the data/users/[user] directory. Messages are hardlinked into both the sender and recipient's Mail> directory. All room directory and message file names are stored in room number and message number formats to allow for non-directory-happy characters.

Every message on the system has a globally unique message number. The next available message number is stored in a file directly in data/ . A message may exist in more than one room at a time by way of hard linking that file into multiple rooms.

The BBS "Blurbs" are stored in data/blurbs/ . These include things like the text files displayed to the user at login and logout, as well as the menus and help files.

An example directory structure might look like:

data/
data/.config
data/users/
data/users/.nextuser
data/users/0/
data/users/0/User
data/users/0/Mail/
data/users/0/Mail/5
data/users/0/Mail/51
  ...
data/users/1/
data/users/1/User
data/users/1/Mail/
data/users/1/Mail/5
data/users/1/Mail/41
  ...
data/users/2/
data/users/2/User
data/users/2/Mail/
data/users/2/Mail/41
data/users/2/Mail/51
  ...
data/rooms/
data/rooms/.nextmessage
data/rooms/.nextroom
data/rooms/0/
data/rooms/0/.config
data/rooms/0/.info
data/rooms/0/1
data/rooms/0/50
  ...
data/rooms/1/
data/rooms/1/.config
data/rooms/1/.info
data/rooms/1/2
data/rooms/1/12
  ...

Potential Object Oriented Design

The idea here is to have the Object model look like the file store. These sample class definitions are just ideas and are not intended to be complete. Lots of things are left out intentionally because I figure they're somewhat obvious or not very interesting at this point in the discussion.

Check out the data classes at Josh and Mark layed them out. This will get expanded as time goes on.

These header files are no longer actively being maintained and will be replaced with the data classes as described above. They're still linked here for reference I used to include fake header files here. Instead, now just look at the real header files.

Messages from NewCit>