Xpress messages need to be saved during login

[dgets]

In order to implement further functionality such as <"> to quote harassing X-messages to the SysOp, as well as allowing forward and backward scroll through the messages, X history is going to have to be saved. I propose that this is handled on a per-user level via a dynamically allocated array of objects containing the sender/recipient's name, a boolean for whether it was coming or going, and the body of the message. It'd be pretty easy to add threading for certain user exchanges, also, not that that is necessary at this point. Might be interesting for an extension to functionality later, though.

[deutrino]

Beware the liability monster. bbs100 clears the buffer after every session, which pisses me off, but you might wanna have it drop old messages after something like 2 weeks. Fortunately I suspect this might be more easily accomplished with a modern system - DOC relied on the usual flatfile ring buffer, with absolutely nothing other than traffic rolling old messages off the bottom.

People are definitely going to want the ^X buffer, which was only written as recently as either eschwa or the flash in the pan that came before it and after Heinous.

[dgets]

I'm thinking of saving only for the session, actually. I don't want that shit written to disk at all. I could do a database and purge it along with other nightly sessions depending on date, but for now it's something that'd be in RAM only.

The ^X buffer is a necessity, yes. Your input on this one is much appreciated, actually; I think you know other users' habits in this system better than I. Any and all feedback on this is appreciated.

[deutrino]

If you have a database which supports memory tables, you could keep the data for the uptime of the server and not write it to disk (except in encrypted swap), optionally capping size by periodically expiring messages.

[dgets]

@gordon-morehouse: I've started doing some brainstorming on this issue again, since pretty much everything that I've found so far for beta functionality it out the door at this point.

One of the problems that I'm not sure about how to deal with just yet is the fact that, unless I find some sort of event/observer model that I can use from within the Synchronet framework, each user's access through the API only really has the ability to grab on to the outgoing messages. Now, since the process is running as sbbs and not a particular user, I can probably compile everything together into a better cross-referenced system on the fly, but I'd definitely like some input on working with this. Being as it's completely new functionality, as well, it might be a great opportunity for you to show me some unit testing shit, too.

Let me know if/when you'd be willing to collaborate on this. The only other thing that I'm really considering at this point for modifications to the shell right now is the floors feature, and that's going to take some much more serious work. I'd rather knock this out first, especially if it lets me learn enough about testing so that I can try to utilize it when I'm working on these other, bigger features.