Yesterday before going bed I had a sort of thought (that's usually scary), then I forgot until now (that's normal instead), so I'm not completely sure of what I'm going to write.
At the moment PMs have some "glitch", in particular when in conversation mode they don't have proper pagination, they have some scary queries (at the moment I have a discussion with 52 PMs at sm.org and the page to load takes 1.9 seconds), they may behave somehow "strangely" (i.e. sorting in conversation mode), etc.
I'm pretty sure it's nothing new in this world (I feel IPB already treats them like what I'm going to propose, but I just know the db schema, so it's a sort of a guess).
So, what about convert them into fully "real" (personal) discussions?
With a "{db_prefix}personal_topics" (equivalent to "{db_prefix}topics") and "{db_prefix}personal_messages" (equivalent to "{db_prefix}messages") and so on.
I know that it would require "something" to be sure only the interested people would be able to see and participate to the discussion (but something like the current pm_recipients should do the trick).
Dunno, just a 5 minutes thought, you are free to destroy it! :P
If I understand correctly. This reminds of other aspects of the direction I'd love to see Elk take: if 'personal_messages' are "more" of a real conversation, that implies that you will be able to share whatever "topic" ("message", "post", "story") with *who you choose*. With more people. That is, "post" something for these and not those.
(yes, you can "send a PM" to who you want, but the perspective, implementation, replies, handling, perhaps layout, is different. And meaning.)
This is the kind of flexibility that, seen from the other side, from the topic-side, means ability to post not only restricted to a (predefined for you) group and in a board. But publicly and to a channel/tag/way_to_categorize, or privately to who you want.
Depending on perspective, it's personal messages that are more like topics, or topics which can be shared more like personal messages. :)
Performance will be comparatively a concern.
On another note, from the user perspective, again this reminds of something: personalized groups (like them buddies, but not only buddies group, random custom groups). Call them as you want.
It's like, yet another step in the same direction. Because it means, do an action like post, to a random group of people. Personalized groups are in the middle between site predefined groups and single users picked when you send the post.
Don't forget that newsletters can be sent in the same fashion too.
I like it, but to clarify,
If I send a message to Eman, Spuds, Arantor,
Eman replied to me, Spuds but NOT Arantor (Sorry Pete!) = Possible or would it be truly like a topic, whoever could see it to begin without would always be able to see replies?
Lets put it this way:
- the first and main "convo" (="topic") is visible to all four of you
- when Ema wants to reply only to two, he splits the topic "to a new topic" (we haz that feature now!), and sends his message to you two. A follow-up convo (=topic) begins. Which is visible to you three out of four.
- probably, the link to the follow-up, in the main convo, should only be visible to those who see the follow-up.
Does that work? Makes sense?
My answer would be: myeah, but there's a difference between the ability to handle messages as posts and easiness to send to a particular three people, and, on the other hand, a link to a follow-up with a different visibility. The second is an extra.
Oooh its like a brain teaser :P
Bug report: Drafts throw's a fit.
Test follow-up and drafts.
What TestMonkey said, plus...I was considering the possibility to "invite" and "kick" (with some alternative ways, i.e. requiring majority, or requiring unanimous decision, at discretion of the starter or of a sort of moderator, etc. I think there are many alternatives here) so that invited members would be allowed to see the entire discussion and kicked wouldn't be able to access it any more.
If something like this is going to take place, the first step I think is make conversation default and probably drop any other mode.
What do you think?
If this is fine, I would go just a bit further and separate the list of discussions from the visualization of the discussion itself.
Any objection? O:-)
Even if I still use the single pm view I'd be OK with that move.
Single is something I was wondering me too, maybe...what about have the list of conversations as usual on top, and when you select one it shows one PM at time with at the top the list of all PMs. It may even be some kind of AJAX to load the PMs one at a time, dunno.
It would mean in some cases one more click...
ETA: and anyway my main concern is drop the all-at-once! :P
Just testing a bit, I didn't change anything important yet.
Removed the menu with the labels and added it on the side.
In fact it reminds a bit a webmail... lol
Just remember that there's an expectation on many sites that PM's will be private, so invites n stuff would have to be handled carefully. On a lot of sites, publishing PM content to anyone who wasn't one of the original recipients is a bannable offence.
As long as the privacy aspect (for those who want it) is given enough thought, the rest sounds pretty good.
I think the invite would have to be unanimous, and frankly I also think it's something the software can't really police. It would have to be handled by the end users. If they're going to share content without everyone's consent, they'll find a way to do it, but I don't think they should be helped to do it.
I think "kicking" is getting a little far with it. I think adding and leaving a conversation makes sense. Trying to think of a schema for this... convo is short for conversation, can use either one.
pm_conversations
convo_id
starter_id
start_datetime
first_message_id
last_message_id
last_message_member_id
num_messages
num_members
label_id
convo_members
convo_id
member_id
convo_messages
message_id
message
sender_id
message_datetime
num_attach
convo_message_attachments
attach_id
message_id
[more stuff about the attachment]
convo_labels
mem_id
label_id
label
num_convo
convo_rules
[stuff]
Maybe another table to show history of when people enter and leave the conversation? Or maybe this is just a "special" message in the messages table? I actually like #2 better
convo_history
event_id
event (enum) [joined, left, invited]
member_id
extra (text, usually the id of the other member)
When I was looking at it, I create a table:
pm_topics
id_pm_head
id_member
id_first_pm
id_last_pm
id_member_started
num_pms
is_new
where, id_pm_head represent the id of the first PM and is also the id of the convo (just because it's already kind of the same thing now, so it cut in terms of headache while upgrading LOL), and is_first and id_last define the boundaries of the convo, so that a query with WHERE id_pm > id_first_pm AND id_pm < id_last_pm AND id_member = {current_member} should be enough to filter out the PMs belonging to a certain conversation for a certain member.
Your is for sure more complete!
I just wouldn't add another attachments table, in my view, attachments should become themselves a sort of gallery available "at any time" (with proper restrictions).
And xref: https://github.com/elkarte/Elkarte/issues/1980
Shouldn't topics be like the topics table which means is_new should be a separate, per user, table? I like keeping the first message as the topic id. Makes sense.
Also makes sense to not add another attachments table. I do think that there needs to be a "link" table or two. This would make the attachments table more robust at least. You would have a msg_attach table and a pm_attach table which would just be pm_id, attach_id and msg_id, attach_id. Though, that might be another topic for discussion.
There is no need to have that level of denormalization in the pm conversation tables. In fact, should make it an item to remove said denormalization in the main messages table. It breaks, often. Would like it to stop breaking.
This table is slightly different from the topics one: each record is "per-user", so there is no need for another table.
The id_member
is the member participating in the conversation and receiving or sending a certain message, so the is_new is really already related to a certain message belonging to a certain member.
Dunno, I have not yet thought about it, but I would invert the link between messages and attachments: it's not the attachment that is associated to a message, but the message that has a set of attachments (please consider my mind is currently a little fuzzy and I'm not sure what I'm typing LOL).
Then, each attachment can have a "privacy level" that can be everybody, only registered, only buddies (for example, and when buddies will be enough flexible to allow create multiple groups, then you will be able to pick one or more groups)... slightly OT here. LOL
NOO!!
/me wants to break things!! :P j/k
rofl You are so funny! I wonder what easter eggs are in ElkArte! Must be a lot! :D
Any bug you find is an easter egg (with some nog)! :P
Since I was stuck on the overhaul of the templating, I started looking into this.
Expect bugs, lots of them! :P
Nice start on a badly needed overhaul ! The PM area is kind of a classic spaghetti code, it works well, but it was fragile to work on / update. So glad this will get redone for 1.1 :)
TBH I'm a little lost with that as well now... LOL
I'm not in a good period coding-wise. :'(
I don't know exactly why, but I think because I tend to spend too much time thinking how to make things "right", losing sight of the goal.
Everybody needs some focusing. No need to fix something that ain't broken should help.
No need to fix what is not broken...
1) PMs are broken, so they should be fixed (broken in the sense of bad design and terribly complex coding).
2) By this idea, we'd be fine with SMF 1.1: it worked, it was not broken, why should have been fixed at all? ;)
Development means "fix" what is not broken to improve it and make it more usable. If we (anyone that develops) don't break anything, we are simply not doing our "job". :P
Of course IMO.
I agree that is some ugly code, it really is :'( So although it may not be broken in the sense that it works, it is broken in the sense that it is not maintainable nor extensible.
You honestly can't figure out what some of it is doing without running a debugger, its gnarly knotted up code, with super crappy variable names. I remember "fixing" a bunch of strange things in it for 1.0, and did some minor structural things, probably added a few comments as pointers of what the heck was going on.
I think some things we may consider dropping:
Do we need the option to not to save your sent messages?
Do we need all those view modes, notably drop all at once?
Yep and yep, from me.
In particular the second one is a pain to deal with.
Also, another thing that is blocking me is the way the messages are rendered in the template. At the moment they are following the Display_Controller trick loading the request in a global and using a function to loop through the callback in the template. Aggravated by the fact that there are two: one for the "discussions" and one for the messages...
After finding a problem, the next step in development is to break it down in to smaller problems. Tackle it as one small problem at a time and commit those. I think that will help your momentum.
Dont mind me if you have time for it. I didnt say you need not improve ot or develop it further. ;)
If dropping all at once helps, I'd say do it. I don't think typical email clients do that (and thats kind of what PM's realy are) where as conversation and one at a time are normal.
Dropping alternatives is always a good thing. nods
I was also considering to drop the concept of sent and received, at best add a "filter" with one of the options a "started by me" thingy. That would probably reduce quite a bit the complexity of the system.
And the fun is great! :D
I started writing code "at random" and when I finished, I realised I did work on a piece of code that was abandoned since SMF 1.0. YAY for wasting time! :D
That's a very antique code. I thought SMF 1.0 code is already a history.
Thats funny!
Yeah there are dead chunks of code floating around, sometimes they are hard to find though, especially in those enormous methods.
One of the other things that is a real pain are the old "word arounds" for issues that probably have not existed for years and years. You have to do a bunch of detective work to figure out what it was trying to fix.