On 12 August 2015 at 09:01, Georg Lukas <ge...@op-co.de> wrote: > * Steve Kille <steve.ki...@isode.com> [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 > > Thanks, this is well worth [re-]reading, as it's a good summary of multidevice issues.
> 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. > > That use-case won't work anyway because Jingle calls are initiated with an <iq/>. > * No filtering mechanism. Carbons are only for type="chat", the client > can't add / remove types according to its needs. > > True; do we need this in order to deploy Carbons, though? I suspect we ultimately do to cover non-IM scenarios, but for normal IM we can probably handle just type='chat'. > * "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. > > I think there's a number of cases where a user's server needs to know that a remote entity is a MUC (and thankfully, with MUC, this is relatively simple to achieve). FWIW, the same issue also affects PEP (where PEP doesn't use headline, at least), but is rather simpler to solve on a stanza-by-stanza basis. For MUC, I'll summarize our conversation online as servers already have to track directed presence to chatrooms; it should be relatively low-cost to check responses and mark those as chatrooms as needed, and then perform a lookup for Carbons purposes. I think I can patch Openfire to do this, and I believe you suggested Prosody may do something like this already (but I may have misunderstood). > * 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. > I made the comment on HN that, as a community, we tend not to try to get a consistent UX, and that perhaps we should, and explaining when to notify (and how) would be a great start - maybe we should kick that off with a Wiki page and see where it goes? > > > 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 ||_________________________________________________|| >
