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

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

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]