* Steve Kille <[email protected]> [2015-08-12 08:14]: > Given that a MAM based approach may be the preferred medium term > approach, it seems to me that we should focus efforts to work out what > the medium term approach is going to be.
+1 > Also, if there is a list of issues that some people view need fixing > with carbons, I think it would be good to have that list explicitly I've tried to compile a more general list of issues some time ago, to be found here: http://mail.jabber.org/pipermail/standards/2015-April/029722.html The carbon relevant things from that list and from the last 0280 advance discussion are: * Carbons for non-"chat" messages. Jingle signalling of incoming calls to all interested clients was mentioned IIRC. * No filtering mechanism. Carbons are only for type="chat", the client can't add / remove types according to its needs. * "False-positive" Carbons of MUC private messages (which are of type="chat"; see http://mail.jabber.org/pipermail/standards/2015-May/029819.html and following messages for a discussion and possible solutions). I think the solutions need to be codified in the XEP. * Carbon notifications (not strictly an XEP issue, rather one of proper UX) - when should a client ring a bell? Recommendations for this case might or might not be appropriate in the XEP. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
