-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/25/09 8:19 PM, Matthew Wild wrote:
> The proposal: > > When publishing PEP updates, the client sends directed PEP updates as > messages (how to do this is already defined in some of the PEP specs) > to the room. This is similar to how presence works currently, the > server does not send presence updates to MUC rooms on your behalf. I like this. You send directed presence to the room, so it makes sense to send directed PEP (often used for "extended presence") to the room, too. > The MUC would then either 1) broadcast the message blindly 2) only > send it to users with the appropriate +notify in their features. > Obviously 1 results in users who may not want PEP updates receiving > them, and 2 requires MUC implementations to track caps and features, > though an in-server MUC module would be able to pool this information > with the main server's own caps cache. IMHO #2 is preferable, if the MUC service is smart. > Now I don't suggest that this is a perfect solution. Everyone should > know there is no such thing :) > > However here is why I believe this method to be a good one: > > - It is backwards compatible with the existing protocols, meaning we > can get it rolled out this side of Christmas (2012) > - It allows the user to decide when and where to share their > (possibly private) PEP information > - MUCs could selectively block or filter PEP notifications from participants Agreed. > But there are some downsides (to which we could look for solutions): > > - It means publishing the same data multiple times to multiple JIDs > from the client The client already does that with presence, so also doing it with PEP (extended presence) is not a great hardship, I think. > - The above mentioned issue of MUC servers dealing with caps does not > appeal to me The life of a server or component developer is a difficult one. > Feedback invited. +1. > I'd like to note that a couple of people I have spoken to would rather > see MUC re-invented, using "cleaner" semantics, and in the process > factor PEP into the mix. We had a similar discussion 7 years ago. Some people wanted to replace groupchat with an IQ-based protocol, but discussions were inconclusive and no one stepped forward to really work on it. I got sick and tired of the squabbling and wrote MUC to be backwards-compatible with the old groupchat approach. I don't claim that MUC is the most beautiful XMPP extension ever developer (nor the ugliest!), but I also don't think it's worth our time to create a new technology that does just what MUC does except in a more aesthetically pleasing manner. > Again I don't claim MUC to be perfect either, > but it works, and we're using it *today*. The MUC XEP is nearly 7 > years old, and is just coming to Final. I am not keen on advocating an > entirely new protocol and seeing implementations mature before we can > finally solve what are now just a few remaining issues with the > current one. Agreed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpE4B4ACgkQNL8k5A2w/vw7wACfbXtgbLgJXSUvJv+5pj7wWEms zo8An2lbGQzKfkup03A6gFWeG+X+2X0Q =QJm4 -----END PGP SIGNATURE-----
