[RFC] Remove messenger system

Note: We are moving the topics of this forum and it will be deleted at some point

Publish your own request for comments/change or patches for the next version of phpBB. Discuss the contributions and proposals of others. Upcoming releases are 3.2/Rhea and 3.3.
Post Reply
User avatar
EXreaction
Registered User
Posts: 1555
Joined: Sat Sep 10, 2005 2:15 am

[RFC] Remove messenger system

Post by EXreaction »

Our current messenger system is quite a mess. It tries to combine two entirely different protocols, email and jabber, into one API.

The big problem with this is, using this system is not entirely intuitive (the API is awful) and it's extremely difficult to extend this system to add other protocols (e.g. sms).

Emails have to, cc, bcc, reply to, from, and more addresses.
Jabber has a to/from address.

These addresses and designs are entirely incompatible, the only way to make one system work with both is to supply every option, then only send things a certain way based on how the user would like it sent. Adding additional backends, such as SMS, would further complicate things.

Instead of having this inflexible system that really limits what we can do/send in messages (e.g. I don't think we could support attachments in Jabber messages, but we could very easily in emails). I propose we remove this system entirely.

I've audited our usage of this messenger system to find where/how it is used:

memberlist
- contact (jabber) -> send an IM
- contact (email) -> send an email

functions_user
- group_user_attributes (approve join request by a user) -> send email/IM per user preference (suggest move to notifications system, http://tracker.phpbb.com/browse/PHPBB3-11745)

acp_email
- mass email -> send email/IM per user preference (suggest email only)

acp_inactive
- activate a user -> send an email
- remind a user -> send email/IM per user preference (suggest email only)

acp_users
- reactivate -> send an email
- admin activate -> send an email

ucp_activate
- activate -> send email/IM per user preference (suggest email only)

ucp_groups
- request joining a group -> send email/IM per user preference (suggest move to notifications system, http://tracker.phpbb.com/browse/PHPBB3-11744)

ucp_profile
- profile updated (reactivation needed) -> send an email if user activation, email/IM per user preference for admin activation required (suggest move admin activation to notifications system, http://tracker.phpbb.com/browse/PHPBB3-11746)

ucp_register
- register (activation needed) -> send an email if user activation, email/IM per user preference for admin activation required (suggest move admin activation to notifications system, http://tracker.phpbb.com/browse/PHPBB3-11746)

ucp_remind
- send password reminder -> send email/IM per user preference (suggest email only)

ucp_resend
- resend activation message -> send an email

install
- install board -> send an email

notifications system
- base class for sending out messages (can easily be split into child classes)

There are a couple changes required, as per my suggestions, but if those were made, the entire messenger system could be dropped and instead we could directly use the IM/email system instead to be able to use all the features of each system and also easily add more systems that can be used.

User avatar
Pico88
Registered User
Posts: 73
Joined: Tue Apr 12, 2011 2:32 pm

Re: [RFC] Remove messenger system

Post by Pico88 »

+1

What is more, IM does notwork if hosting does not provide support by unlocking ports, which IM uses. In that case, it is useless.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Remove messenger system

Post by MichaelC »

This was recently brought up on IRC when trying to integrate it with part of the website.
Some points I noticed:
  • The whole system of how it queues messages needs to be made easier
  • The system also needs proper documentation
  • It should be more flexible/extensible
  • It should also be a lot easier to send a message without a language file (specify the text of the email in the code)
  • To, from etc. should have separate fields for a name and address and name should not be required.
  • It should not really require usage of the user class (It doesn't require it now as far as I can see, it's just built around your way of using it).
  • Easily add new notification types which will integrate with phpBB (appear as notification types in notification options, be able to specify in the code which method to use or preferred method, disable/enable methods in the ACP, options for each notification type etc.). Extensions should be able to do this.
  • It should be possible in the code to specify how to send messages over-riding the board settings (i.e. a from email address or the signature).
  • It should be possible to use html templates from the main board templating system
Another idea could be to integrate a library like swiftmailer for the mailing.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

Post Reply