Page 1 of 1

A cross between Instant Messaging and traditional PM

Posted: Thu May 25, 2006 3:43 pm
by evilmonkey
Hi everyone,

For my next addition to my site, I have decided to do something different. I have decided to cross private messaging with instant messaging. Basically, once a "conversation" has been started (i.e. the initial PM has been sent), all replies will be added to the same PM. This will make it much more friendly for my users as well as will reduce the clutter in the database (in our current PM system, every message, reply or toherwise, gets a row in the database). A "conversation" can happen only between two people, so there's no need to worry about multiple recipients.

Now, for the trick. Each user should also have a sent box and a trash. When a user iniates a conversation, it ends up in his "sent" box along with all the replies that take place after. If a user replies to a conversation he did not initiate, it does not end up in "sent". THe trash is just a place where deleted messages go till they're deleted permanently.

Okay, let me demonstrate with an example: John Doe sends Jane Doeth a message. It goes into John's "sent" box and Jane's "inbox". Jane replies. Jane can immediately see her reply in her own inbox, and John sees Jane's message as well as his own in his inbox. John then replies and sees his message immediately in his inbox, and it goes into Jane's inbox. By the time these three events happenned, John inbox, John's sent, and Jane's inbox look like this:

Code: Select all

(oldest messages on the bottom)
...etc
John:
Also not bad. What'd you think of Edmonton winning over Anaheim?
Jane:
Not too bad, yourself?
John:
Hey. How are you?
Now, let's say John deletes the convesation. It has to go into John's trash, but needs to stay in Jane's inbox until she deletes it.

Now, I had a couple of ideas on implimenting that, but hit a roadblock each time. My initial idea was to have each conversation as a record in the database, and use that record for both people in the conversation. I hesitate to use words like "sender" and "recipient" because each person is, in a sense, both a sender and recipient. So my idea was this: set up a table with two user feilds and a message field that would be updated once replies are sent. In that sense, there is only one row for each active conversation, reducing the clutter in the database:

Code: Select all

User1              User2                 Message              Trash       Inbox    Sent
==================================================================================
John                Jane                John:                          0              1           1
                                      Also not bad. What'd you 
                                       think of Edmonton 
                                      winning over Anaheim?
                                      Jane:
                                      Not too bad, yourself?
                                      John:
                                      Hey. How are you?
However, this takes only the point of view of one user into account (in this case JOhn, since he would be the only one who has it in his "sent" box since he iniated the conversation). How can I do this so it takes into account the point of view of both users?

Let me know if tat was clear...it's really kind of difficualt to explain, but it's a simple intuitive idea once it's implimented. I'm looking for the most smart and efficient way of doing this. Let me know if I just won the "vaguest explanation of the year" award.

Thanks! :D

Posted: Thu May 25, 2006 6:37 pm
by santosj
Just another awesome feature my visitors are going to complain about not having.

Posted: Fri May 26, 2006 2:45 am
by Maugrim_The_Reaper
I'm voting for you in next year's awards...;)

Not sure if I understood you right, but is this more a database design question? Why not isolate each posting like any PM system, give each a conversation_id, add a conversation table to track involved members, then at runtime grab the convo id (or the id from a requested PM), grab all previous posts for this conversation, and order by time. Maybe I'm pushing you up the normalisation ladder (??), but you can drop back down for performance later if required...

I suspect you're hitting a brick wall because of premature optimisation - break it down (who cares how it performs just now), get it working, test it, then consider a little refactoring and performance benchmarking.

I think it's a cool idea by the way - would be nice if I could easily track a PM convo in phpBB at times...

Posted: Fri May 26, 2006 3:03 am
by santosj
yeah, but if you were to create a new table for it and then combine it into the pm table, couldn't it get huge if you have a lot of visitors and users of that? Also, you would need to have some way for notication and for getting a update. Which would work fine in a new window. The bottom half could be the text area with the submit and the top part could either use AJAX or a refreshing window frame.

I think it would be better to create another table for it and then just combine the conversation into one pm at the end. It would be transparent from the user anyway.

The trash thing I find probably needs another table also. It was difficult for me to implement a PM system that allowed for one to delete a message and still keep it for the other without having two or more copies. Since I didn't want to have to or more copies of the say message, I just created another table that had the status of the pm for both of the people who sent it. If both of them deleted the pm, then it was deleted from the table. It also allowed me to implemented a 'read' notication if the user wanted to see that.

Come to think of it, I don't think it would be all that difficult to implement this type of setup. I'm going to try it in the current development project that I'm working on.

Posted: Fri May 26, 2006 1:57 pm
by evilmonkey
santosj wrote:yeah, but if you were to create a new table for it and then combine it into the pm table, couldn't it get huge if you have a lot of visitors and users of that?
What is IT? I am scrapping the PM system I had before, this will replace it. For now, the idea I'm hearing is to still have one entry per message, but put all the messages in the conversation together at runtime using a convo_id. From this, I have another idea: get two tables; one table will have a row that looks like this:

Code: Select all

convo_id  |  user_id  | inbox  |  sent  |  trash
So user_id 1223 is involved in conversation_id 10099 and he has it in his sent box and his inbox, it would look like this:

Code: Select all

10099  |  1223  |  1 |  1  |  0
If the other user in the same conversation (let's say user_id 3221) has this convo in his trash, his entry would look like this (a seperate row, completely unrelated to the first one)

Code: Select all

10099  |  3221  |  0 |  0  |  1


The other table would just have the convo_id, the text of the actual conversation, and the date the conversation was last updated. In this way, I can either do it my way (update one row each time a message is added to the conversation) or Maugrim's way (add a seperate row for each message with a convo_id).

What do you guys think?

Posted: Fri May 26, 2006 6:07 pm
by santosj
That is the way I did my PM system. However what I stated was a combination of both methods. Using that system you can keep the conversation table with as little as rows as possible while you add the finish conversation to the pm table. It would also be easy to add the new feature.

Code: Select all

if((user1.convo_id == user2.convo_id) and ((user1.trash != 1) or (user2.trash != 1)))
{
update();
}
This will check to see if either of them trashed the conversation and if not then keep the conversation open. If not then end the conversation and send the conversation to the person who didn't trash it. You could also check from time lapse and close it that way.

Posted: Sat May 27, 2006 12:59 pm
by evilmonkey
Implimenting it now...thanks guys. :)