Hi All,
I have poked around the mod_log_chat module and managed to get it to log to user's Maildir. Since I have precisely _zero_ erlang skills, I'm not going to even suggest it for inclusion in current shape. However, I believe that the gtalk-like logging is valuable and would like to share my ugly hack with people that actually can program in erlang in hope that they can build on top of that proof-of-concept.
The patch is available here:
There's more information on it's limitation (i.e. for now, no vhosts) there and please accept my sincere apologies for poor code quality. This is the first time I even saw erlang.
I will check this thread for any further questions for a couple of days but after that please consider contacting me directly via the email address published on my page.
Regards,
--
Jaroslaw Zachwieja,
Centre for Scientific Computing, University of Warwick, UK
Modified patch with some
Modified patch with some changes that you may want:
* Use Direction of the stanza delivery to decide who to consider Local and Remote
* Use an Erlang md5 function
* Remove an IF bifurcation that seems useless (later I realized there's many more useless code)
* In the filename, identify as JID, not as username
* Fix indentation using Emacs
Thank you. Unfortunately, I
Thank you.
Unfortunately, I am well aware that it was poorly written code. :)
The reason that I had the entire main if statement duplicated with Local* variables was that when both users were on the same server, they both needed the logs -- first user would get it from a conditional execution (if from = to) and the second one would be treated like every other case.
I'm sure it was the wrong _way_ to do it (erlang was very rude to me when I had variables local to if statements ;) but I believe that there are two separate cases that need taking under account -- local+local and local+remote (remote+local being == the latter).
If it was a case of two different servers, only the local one required the logs.
With your patch, I realised, that in case of local+remote, every line is logged twice. The local+local logging works fine.
I believe that if I enclose the first logger (the one with Local* variables) in:
ifFrom#jid.lserver == To#jid.lserver ->
the whole Local...;
From#jid.lserver /= To#jid.lserver ->
ok
end,
then the logging is only done once for both local+local and local+remote scenarios.
What do you think?
I have also modified the components of the MD5 hash to:
FromPart = From#jid.luser++"@"++From#jid.lserver++"/"++From#jid.resource,ToPart = To#jid.luser++"@"++To#jid.lserver++"/"++To#jid.resource,
so different resources log to different files.
There is one side-effect to that, the first line of user1 -> user2 will be logged to one file and then the continuation of the conversation starting with the first user2 -> user1 message will be logged to another. I would argue that this isn't a major flaw as my aim is to have 'searchable' logs from within the email client. The premise is still there.
I have tested a new patch (still logging to username, not username@host, sorry) and have published it on my webpage.
Edit:
There are occasional errors in the ejabberd log:
=ERROR REPORT==== 2011-06-15 14:50:46 ===E(<0.364.0>:ejabberd_hooks:294) : {if_clause,
[{mod_log_chat,write_packet,5},
{ejabberd_hooks,run1,3},
{ejabberd_c2s,session_established2,2},
{p1_fsm,handle_msg,10},
{proc_lib,init_p_do_apply,3}]}
running hook: {user_send_packet,
[{jid,"localuser1","localdomain1.uk","38947283631308141624863638",
"localuser1","localdomain1.uk","38947283631308141624863638"},
{jid,"remoteuser1","remotedomain1.com",[],"remoteuser1","remotedomain1.com",[]},
{xmlelement,"message",
[{"type","chat"},
{"id","purplef8e5158c"},
{"to","remoteuser1@remotedomain1.com"}],
[{xmlelement,"active",
[{"xmlns",
"http://jabber.org/protocol/chatstates"}],
[]},
{xmlelement,"body",[],
[{xmlcdata,<<"test message.">>}]}]}]}
When that error message occurs, the message isn't logged. That error occurs with your patch (with my local=remote if statement) but doesn't with my patch (that now has the md5 code incorporated).
Ok, then continue improving
Ok, then continue improving your patch, if it works correctly.