Tobias Markmann wrote: > I think for its most common use case, MUC or PubSub, you will > end up with one repeater for each room(MUC) or node (PubSub) and if > those IDs change each time someone joins or leaves it just adds > complexity.
So the repeater service creates the repeater JID however it wants and never changes it. That's well within the spec as written. > A similar optimization could be done by removing deletion of a > repeater by its creator and hand that task off to the repeater > component itself. MUC and PubSub codes don't have to care about a > repeater when they don't need it anymore; just forget about it. The > repeater component removes unused repeaters after a certain timeout > and informs the creator with a message. Sure, that makes sense, just let the repeater get garbage-collected. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
