#397 [mod_muc] provide default_history_messages

Reporter dittler@informatik.hu-berlin.de
Owner MattJ
Created
Updated
Stars ★★★ (6)
Tags
  • Type-Enhancement
  • Patch
  • Milestone-0.10
  • Status-Accepted
  1. dittler@informatik.hu-berlin.de on

    *Description of feature:* Please provide the possibility to mimic the behaviour of ejabberd and provide an option how many history messages a server should send, when joining a MUC. With client which don't implement XEP-0045 properly (f.e. Pidgin/libpurple) this is really valuable.

  2. dittler@informatik.hu-berlin.de on

    I implemented it myself. With "default_history_messages = 20" everything will stay the same, otherwise it will send default_history_messages to clients, which don't request a specific number. Can we push this into the module?

    Attachments
  3. dittler@informatik.hu-berlin.de on

    i made a better patch that is configurable per room

    Attachments
  4. MattJ on

    Changes
    • owner MattJ
    • tags Status-Accepted
  5. MattJ on

    Hi, thanks for the patches! Both look good. Do you need the functionality of the second one? (per-room configuration). If not, I lean towards merging the simpler smaller one, I don't currently see a case where you would strongly want this to be per-room.

    Changes
    • tags Type-Enhancement Milestone-0.9
  6. dittler@informatik.hu-berlin.de on

    Hey Matthew, I have no specific need for patch #2. It was a suggestion by Zash. #1 is fine with me.

  7. dittler@informatik.hu-berlin.de on

    Why didn't it make this patch into 0.9.5 or 0.9.6? I'm waiting desperately.

  8. dittler on

    I use the moving of the issue tracker to point out, that there are still two unmerged patches in this issue.

  9. C. Schanck on

    Really, really waiting on this. Any news?

  10. MattJ on

    Sorry, for some reason I thought this was in already. We're working on a new release shortly, will take a look at it.

  11. Mykhailo Danylenko on

    Inclusion into the upstream will be appreciated - I need this feature too. Thanks in advance!

  12. Mykhailo Danylenko on

    Hey! 0.9.9 and 0.9.10 had come out, but this is still not in the upstream! Bumping.

  13. akosiaris on

    Bumping as well. Please include this patch. I had to locally patch my prosody install everytime I upgrade

  14. Zash on

    Changes
    • tags Patch
  15. dittler on

    Bumping this another time. Why not include it in 0.10.*?

  16. MattJ on

    Hey, you're right... sorry about the poor handling of this issue. Working through our backlog of patches is one of my top priorities at the moment. I will be looking at merging 2 patches today for MUC in 0.10, and this is one of them.

    Changes
    • tags Milestone-0.9 Milestone-0.10
  17. MattJ on

    The patch is merged, and will be in the next 0.10 nightly build and the 0.10.2 release when we make it. Thanks for the contribution, and once again apologies about the delay in merging it.

    Changes
    • tags Status-Fixed
  18. MattJ on

    Looking at trunk (where the MUC code has been significantly rewritten), it has a different behaviour. The history length of the room is configurable (per room). By default it always sends all the history. Do you still require the number of messages sent to be configurable separately from the number of messages actually available in the history?

  19. MattJ on

    Ignore my last comment, I managed to port the patch so the behaviour should be identical in 0.10 and trunk now.

  20. Jonas on

    Has this patch been merged and released in one of the subsequent 0.10 releases already? I wasn't able to find the corresponding commit.

  21. MattJ on

    Sorry, I meant to re-open this issue. Numerous problems were reported after merging the patch, and due it being a stable branch and a security release that everyone would need to upgrade to, we reverted the base commit and the fixes on top of it. https://hg.prosody.im/0.10/rev/463505cc75d5 If someone can provide an updated patch for 0.10 that is well-tested, I'm still not opposed to including it. As it is, I don't have time to work out these issues myself as my focus is on getting the next branch ready for release.

    Changes
    • tags Status-Accepted
  22. dittler on

    With MAM being the standard now, this patch is not important to me anymore. If anyone wants, please work on it, but otherwise let's forget about it.

  23. Jonas on

    I'm also ok with dropping the patch alltogether if @dittler doesn't need it anymore.

New comment

Not published. Used for spam prevention and optional update notifications.