|
|
|
|
|
|
New Message System SpecJay Bonci jaybonci@everything2.com
(I) Abstract Why change the message system? The reasons are many. As our site grows, and our communication needs change, it becomes obvious that the message system to chat with other users on the site needs to be overhauled. Many of the features that worked for the site in the last three years have held the community together and really have watched it grow to the point where those features need to be expanded. It needs to be overhauled because we need deeper integration of many functions. Right now things like borging, msg-alias following and other items are not seamless for the coders. We need to special case in those items in all areas for them to be followed. Code duplication really is something that I would like to avoid as it makes an already large codebase much harder to maintain In addition, certain portions of the message system are not modular enough to be maintained efficiently. For one good example message, the opcode, is a gigantic switch statement based upon what type of msg command you are going to send. Therefore if I wanted to work on a /beer command, there won't be any message system until I work out that component (the msg opcode will continue to fail). It's bloated and this overhaul is a good way to resolve it. Design goals of the new message system The main numero-uno goal of the message system is complete HTTP-form backwards compatibility with the old system. There will be a time when the old system is still in play and we have a different (but identical) interface to the new system for testing. All commands will go through op="message". This is important as we do not want to have to change the way older clients work, and the general way the E2 forms work. We need to incorporate all the features of the old system into the new one, in a seamless manner to simplify code. There is also a need to make it easily expandable. In the future, adding easier ways to communicate en masse, and add new features to the system should be interesting and easy. The message system should be almost like a command-prompt interface into E2, much in the same way the Quake prompt works. We'll strive towards that goal with plug-in based modules. When is this going to come in? Soon. I'd like it to come in, as there are a lot of people (both here, perlmonks, and people with private ecore) crying for a new system, and this would be a good way to pull all of our concerns together. I don't have a specific time. Testing integration into the existing E2 structure is going to be the hardest part. (II) General Architectural Changes The message opcode will be changed over to be considerably simpler. The functionality for each message type will be moved to it's own nodetype (see msgcommand below). The job of the message opcode is to make sure that guest user can't execute anything, and to parse the message command into it's msgcommand type. The message opcode will split the message as follows:
/msg jb Hey there, hows it going
^^^^ ^^^^^^^^^^^^^^^^^^
msgcommand Part sent off to the message plug-in
The system will look a lot like the HTMLCODEs that ecore programmers are used to, but will simplify the mass of regular expressions that we see now. It will also default the system to msg the main room if it doesn't match /\/(\W*?)/.
The message alias system will be ported over to a newer, more expandable system. Currently, we use the chatterbox forward setting. Don't worry, you don't have access unless you're an @, however it's nothing more than a mapping of short names to that of long names, so you're largely not missing out. This setup has the scalability woes of any sort of setting glob in that it's great if you need ALL the items in the settings hash, because you need to parse them to pick them up anyways. However, since we need to only map one to one usually, this may be less than ideal. Message alias translation is a tricky process, and involves several concerns:
Editors have a note feature that we use to keep information on homenodes about who is talking to / working with whom. And it gives ailie a chance to be silly. For those two reasons, we're going to have to keep it around. It's currently listed as a quickly filling up setting which could stand to be moved to it's own system. For that reason alone, we're going to move it to it's own table and have the message system run it. It's a good a time as any to overhaul this system. You'll be able to add editor intel by using a /note command or something similar. There will be changes to the way that massacre and blab work, if nothing more than to simplify the underlying code. We need to make sure that if people have a second account that forwards to their first acct (such as tbbk => TheBooBooKitty), we need to make sure that the Klaproth / blab! messages automatically, and seamlessly forward. Currently the ignore mechanisms are very over-the-top. They aren't ingrained into the message system anywhere useful. We need to check each time we send a message as to whether or not they are ignoring it. Since our current way of sending messages is a simple sqlInsert into the database, we need the messaging functions to check for that ignorance. The borg function is similar. We currently check $$VARS{borged} to determine whether someone is borged. $VARS are by no means a good storage mechanism. It's quite volatile, and there are many race conditions associated with it (we will be moving on over to param tables like slashcode does in the future, but for now, it stands as it lies). The check is per message function as to whether you can speak. In the message opcode, in the blab code, etc. This needs to be more uniform There will be a general table for messages blocks. You can put them in manually, if you would like, in the same manner as your block list currently works (check your Decline Private Messages filter in your Preferences). Borging will be morphed into a forced block put upon you against node_id=0. This means that you won't be able to send any message. There will be a parameter on it that will cause it to expire. Expiration of blocking is another thing that we will have to check. We may percolate this functionality down to normal inward-bound blocking, but for now, it's not a timed thing. Very little will change about general messaging and chatting except that now if a normal user tries to send a super-user command, it simply won't go through. It will not shout itself to the chatterbox. It's a design choice that has to be made. Typo checking will catch any message that starts with "msg" or ".msg". The likely typos "/smg","/mgs", etc will be aliased in the same manner that "/tell" is aliased to "/msg". (III) Feature enhancements Note: these are experimental, and may not make it into the final version of the messaging system Due to the abstractions available to us, a possibility is to include certain rooms in usergroups for announcements other other purposes. There are several roundabout uses for this, including creating an announcement list that also announces something to a channel (such as an edev channel). It's tough to imagine uses for it now, as rooms are an underused feature, but the broadcast nature of this may make it worth while in the future. Similar to the ability to create rooms, creation of folders seems like a likely next step for people. It would utilize the in_room portion of the message table, and (if we made sure the cleanRoom.pl did not wipe them out), we could allow higher-level users (with piles of messages), to get a better way of organizing them (other than turning on Message Inbox Threading, which will still be available). Sent messages folder A largely requested feature of our current message system is the ability to save old messages in a "sent" folder of sorts, keepable until they are deleted. These will be up in an off-table for sent messages, until they are deleted as normal. (IV) New Nodetypes The new msgcommand nodetype is a modular extension to the message system. It will most likely derive from htmlcode (in the 0.8 version at least), and will run similar to that. It will have to use Everything::Message as it starts, but after that, it should work just fine. The msgcommands will be named in the part of the message after the /, so they could be "msg", "tell", "topic", "borg", "beer", etc to correspond with the appropriate command. They will be called with evalCode as they would normally be called through the htmlcode() function. The pre-1.0 system may use evalCodeX depending on whether they get put in chromatic's compil-o-cache. I have yet to test extensions of nodemethod or htmlcode in the newer version of ecore. The msgcommand plugins will take one parameter, which is the string after the intial command and a space. It's not the most intelligent parsing scheme, but it's a good standard to adhere to. In the rare case when it's less useful (/me, etc), it'll be easy enough to pre-append the string and move on with life. It's up to each msgcommand to parse that truncated string. We'll provide a parameter to remove the first item(s) from the string, since it's a common usage, but for other plugins (such as /topic), we'll want the whole thing, so by no means will it be standard. Nodes of type msgdelivery will also descend from htmlcodes, but will be used when the msg delivery to objects is not completely obvious or essential to the code, and needs to be extended. When a node fails to be a user or usergroup, then the next step is to see if a custom handler is in place for the delivery type. Each node will expand to a type. In pre-1.0 this might be handled by nodemethods, but in 0.8, we'll have a standard type for this. You could use standard messaging to log to either a logfile by overriding the method, or by adding to a wiki, for instance. It is up to the site authors as to how this gets extended. (V-1) Public interfaces in Message.pm
translateAliasNumber($FORNODE)
hasMessageBlock($NODE, $USER)
installMessageBlock($NODE, $USER, %blockoptions)
removeMessageBlock($NODE, $USER)
notateNode($NODE, $USER, $msg)
moveMessage($MSGID, $USER, $FOLDER)
sendMessage($for_str, $USER, $msg, %msgoptions)
sendMessageToNode($NODE, $USER, $msg, %msgoptions)
deliverMessage($FORNODE, $USER, $msg, %msgoptions)
(V-2) Private interfaces in Message.pm
(VI) Anatomy of a sent message (VII) Changelog
|
|
|
| This affordable entertainment brought to you by The Everything Development Company |
|
