http://moodle.org/mod/forum/discuss.php?d=76255):

Yes, the move to using Events to pipe all mail through one system and the ability to decide how to redirect messages based on plugins will almost certainly be in 1.9. The new YUI-based interface may not, we'll see.

I'm waiting for Martin to merge it.

Just wait a couple of weeks

http://cvs.moodle.org/contrib/patches/messaging_v2/

Work continues on getting it into Moodle core in 2008: http://docs.moodle.org/en/Development:Messaging_2.0

Two comments that come to my mind while looking:

1) Is supposed that each user is going to be able to specify:

a) one preferred notification method for the whole moodle server.
b) more than one (simultaneous) notification methods for the whole moodle server.
c) one preferred notification method for each communication facility (forum posts, messaging, alert emails...)
d) more than one (simultaneous) notification methods for each communication facility

Obviously the more complete is d) where each user can say how he wants to be notified for each facility. mail for forum posts, jabber for messaging, sms for grades... all them supporting multiples (jabber and sms for grades).

2) The "jabberclass" library... could it go to /lib ? I can imagine other parts of moodle being able to communicate with jabber server... say chat module (new type of, like the daemon one) or so.

Ciao

1)
a-ok I'm redoing the user messaging preferences form to make it simpler. This will be considered
b-that already exists, the user may specify with processor he/she wants to use
c-all the communication methods register as providers, the user then chooses the type notification per provider
d-also done

2) I still need to think about the best way to use the jabber class since, now for each message it needs to connect and login to the server (the connection should be at least cached)

Tx for the comments

1) We need to support more types of messages, more than one per module. So I think we need to change the message_providers table to have:
id, name, component, capability
The capability lets us restrict display of certain message types to certain people (eg some will be for admins only), it'll be checked at system level. We can derive the proper string name from these the same way capabilities do (see get_capability_string), by looking in the component language file for a string derived from the name. eg look in forum.php for "message:posts" and "message:digests"

2) The use of events to register/unregister the providers has turned out to be a bad idea, since they are not really events. Also in the lib/db/install.php there is a hardcoded insert into the database which there should not be. So we need to remove those forum_install() type functions and the hardcoded data in lib/db, and instead we should move to using db/messages.php files, which look very similar to lib/db/access.php and lib/db/events.php files and work the same way. This way it'll be easy to add/remove message types at any time.

eg in lib/db/messages.php

$messages = array (
'moodle:system' => array (
'capability' => 'moodle/site:config'
),

'moodle:errors' => array (
'capability' => 'moodle/site:config'
)
);

and mod/forum/db/messages.php

$messages = array (
'mod/forum:posts' => array (),

'mod/forum:digests' => array()
);

eg http://cvs.moodle.org/moodle/mod/forum/db/messages.php

Luiz, can you now complete the other modules in the same way? Note that the objects passed to events_trigger need to contain these two parameters for component and name:

$eventdata = new object();
$eventdata->component = 'mod/forum';
$eventdata->name = 'digests';
$eventdata->userfrom = $site->shortname;
$eventdata->userto = $userto;
$eventdata->subject = $postsubject;
$eventdata->fullmessage = $posttext;
$eventdata->fullmessageformat = FORMAT_PLAIN;
$eventdata->fullmessagehtml = $posthtml;
$eventdata->smallmessage = '';

It's on message/edit2.php

I wouldn't think this would be easy to port to 1.9 (and due to restrictions on what we can add in the core stable branch, it couldn't go in 1.9.x anyway).

It is disappointing that we will have to create something to satisfy the need now and then rewrite it to work once 2.0 is released and our clients are willing to migrate to it. Thank you for the update I look forward to adding notifications to our blocks and modules once 2.0 is released, it looks to be well designed, and I like the multiple communication types.