Re: Need ideas about better ways to manage private messages. (old plans)

There are some very simple changes possible.

We have an int that says 0 for unarchived and 1 for archived. Add the ability to define "folders" by just storing a mapping between values 2..$n and folder names in user settings. Then add an "archive to" drop-down to message inbox so when you archive messages, they go to a particular 'folder'. Note that this requires no additional DB features nor capacity.

Add checkboxes for "delete all but" and "archive all but". Some would do this with JavaScript that actually checks all of the boxes. But I see little point in making such a feature not work for those who choose a browser or configuration lacking in JavaScript.

Add fields for "from" and "containing" (and "folder") so message inbox can act like a not-very-super search for private messages.

I don't see the point in separating un/archived messages between tables. That adds commplexity and DB load (for copying records where we used to just set an int).

I do see a point in separating public chatter and private messages into two tables. If we do that, then I'd add an int for representing the sender's "folder" selection. Then I'd change "delete" to set the "archive" int to -1 so the sender and recipient can see the same message and delete it when either feels like it w/o doubling storage requirements. (Messages where both parties have selected 'delete' would get purged from the table -- delaying this purge would even allow for an 'undelete' feature.)

I already have reasonable search capabilities for private messages. I have more private messages than just about anyone, but I can search them by going to message inbox, setting the number to display to 2000, then using my browsers 'find' feature.

But a big advantage I see to adding the above (fairly simple) 'search' features, is that it allows me to get a bunch of related messages together so that I can archive (or delete) almost all of them to the same "folder".

As for exporting batches of messages, I'd use the existing features (XML ticker). That way people can pick the format they want with much greater flexibility.

- tye

Comment on Re: Need ideas about better ways to manage private messages. (old plans)

Replies are listed 'Best First'.
Re^2: Need ideas about better ways to manage private messages. (old plans) by demerphq (Chancellor) on Nov 26, 2005 at 19:12 UTC
Ok, this sounds like a pretty good high level design. I can work towards this. Regarding splitting public chatter out of the message table. I have prepared patches to add_public_chatter and repeatedchatter to switch this over. Nothing else that I can see needs changing as those changes already occured when I did the CB caching work. (Well, 'oldcache' support would stop being useful, but thats ok.) Having said that, in my trawls through the internal code archives I did come accross some nodes which ive marked with 'Dead Code' patches that i believe should be applied. They seem to be initial attempts at what I did with add_public_chatter, (insertmessage is an example.) Any thoughts? If I see stuff that doesnt look like active infrastructure nodes can I dead node them? --- $world=~s/war/peace/g	[reply]
Re^3: Need ideas about better ways to manage private messages. (old plans) by tye (Sage) on Nov 27, 2005 at 03:29 UTC
repeatedchatter was the first refactoring bit that actually got applied. I disliked how huge the message opcode routine is and started down the road of making each chatter /command a separated node with common routines for parsing out a user name/number, etc. I got distracted making something like htmlcode() but that could return a list and so never split up the big elsif block. And repeatedchatter turned out to be enough refactoring such that 'insertmessage' and such weren't a high priority. However, they still might be useful for places like '/msg me when I get a reply' and such; but those don't matter for this table split since it is the public chatter that is moving. So I'd still like to eventually split up the message opcode by returning output values via a passed-in hash ref (a technique I think you came up with). And eventually remove the last couple of 'insert into message' chunks of code (unless they are already using repeatedchatter). But when you identify code that would no longer be useful for such refactoring, make it as dead, sure. - tye	[reply]