On Tue, May 28, 2013 at 11:26 PM, Lance Stout <[email protected]> wrote:
> After reading the new proposed Chat Markers XEP, the thought occurred of why
> are we using explicit enable/disable queries for Chat Markers and Carbons?
>
>
> What if we instead make it so that if you want to use them, advertise support
> for the features in caps and then the server automatically enables them. If
> you don't want to use a feature for a given session, don't advertise support
> for it.
>
> Benefits:
> - Simplified protocol, works similar to PEP
> - Fewer requests/responses needed to fully establish a session (ie, faster =
> better, esp for web clients).
>
> Cons:
> - Enabling/disabling a feature requires presence update, with associated
> presence storm issues.
> - ?
>
> As for presence storms, I'd say we'd have the exact same issue that we
> already have for enabling/disabling interest for PEP nodes, so it shouldn't
> be that big of an issue. And Carbons/Chat Markers are the type of features
> that would typically always be enabled, not flipped on and off constantly.
PEP, though, is something where your contacts(' servers) enable it
based on the presence they receive, and the presence storm is
necessary for telling them about the change. Carbons/Markers are
local.
My opinion at the moment is that the current toggle is the sort of
protocol wart that it's possible to get caught up in, but really makes
no practical difference to anyone beyond aesthetics - this is only a
couple of extra bytes sent, it is not an extra roundtrip on the
startup. That said, if people agree this is something worth
addressing, would toggling the default to true if you advertise caps
suit everyone? Then you don't need to send extra data to start the
stream, and you don't have a presence storm if you do decide to not
use it?
/K
