in reply to Need ideas about better ways to manage private messages.

1800 private messages? What do you think this is, gmail? Oi. I'm overwhelmed when I have three messages still sitting around... :-)

I would suggest the following options would be made available (all of them as a group):

  1. Copy all private messages as a single email to the email address on file for your user.
  2. Copy all private messages as separate emails to the email address on file for your user (only available if you have a reasonable number of private messages to send - no filling mailboxes with 50+ emails!)
  3. Move all private messages as a single email to the email address on file for your user. Warning: if that email address is incorrect, you will lose all your private messages.
  4. Move all private messages as separate emails to the email address on file for your user. Warning: if that email address is incorrect, you will lose all your private messages. (only available if you have a reasonable number of private messages to send - no filling mailboxes with 50+ emails!)
  5. Delete all private message (useful if you just copied to your email and confirmed delivery).

Optionally, don't have the two move options - just the two copy options and the delete-all. The nice thing about the move options is that if you get a private message between copying to email and verifying that it was received ok, you may accidentally delete that new message without seeing it, and that would be bad. A single move option could theoretically do the sending and deleting in a single SQL transaction (are we using an transaction-capable db?) to avoid that race condition.

Giving the user the ability to type in an email address at this point seems silly - although spamming someone else with 45 tiny emails is still possible by updating your user information to someone else, I'm more thinking about the likelihood of a typo. Once you get it right in your user information, you can generally just use the move button and not worry about anything.

Update: I should make this clear - my position here is that PM is a public web resource, not an email replacement. Adding in a webmail-type interface is, I think, not a productive use of the pmdevils time. (Spending that time with loved ones should rank significantly higher, for example. As should spending that time downvoting every single one of my posts. That's not an invitation ;-})

Instead, offer the ability to send the messages to an email. And, selecting that, perhaps get them in multiple formats: plain text, html, xml, or attached csv (including header). Then, with the predictability of a guaranteed "from" address, perhaps a good subject line, and/or an X-PerlMonksMsg header of some sort, you could easily write some code to execute on receipt of such a message to insert it into your favourite database (whether that's MySQL, PostreSQL, DB2, Oracle, or another CSV file or XML file or whatever) and do whatever you want with it. Without clogging up PM, PM's CPU, disk space, etc. You can query it seven ways from Sunday, and never have to wait for some pmdevil t share your itch on how to look at the data.

The only reason for individual email option is to allow you to sort everything in your email program into folders or whatever, if that is the way you want to do it. In this case, you would simply send all the metadata (who from, and any other metadata you have about it) in X-Perlmonks-* headers, and let the user figure out how to get what they want from that.

I really think that anything more is a solution looking for a problem, and that it'll find more than you can chew on. Instead, let each of us find our own way with the data, and any interesting ones will show up in Cool Uses for Perl anyway.

  • Comment on Re: Need ideas about better ways to manage private messages.

Replies are listed 'Best First'.
Re^2: Need ideas about better ways to manage private messages.
by demerphq (Chancellor) on Nov 25, 2005 at 08:23 UTC

    With regards to the copy/delete option, I was thinking that I could add a field to the message object/record that would hold a send id. So when you migrate to an external source like email the send id would be set accoridngly and the email would contain a link back to the site with the appropriate params that would delete all the messages with that send id.

    Regarding formating, we already provide XML feeds for the private messages, and a webpage view, so i reckon the email would be something amenable to reading, and naturally, simple perl based parsing.

    ---
    $world=~s/war/peace/g