[Proposal] Add echoMessages flag at the channel level

[mattheworiordan]

Seeing as though we're adding a lot of new flags to channel attachments, should we consider a flag to allow developers to override the echoMessages enabled/disabled default set at the connection level? I assume we could consider this if / when we enable client side explicit attachment flags.

WDYT @SimonWoolf @paddybyers @tcard

┆Issue is synchronized with this Jira Task by Unito

[SimonWoolf]

If we've got customers asking for it, sure, not hard to add.

Would need to think about the semantics of how it interacts with the connection params -- most trivial to implement would be a SUPPRESS_ECHO flag where message is not echoed if have either that channel flag or echo=false (as can leave the connectionmaster check as-is and add a second check at the attachment level). But if you want it to be able to override both ways round, could have that and a FORCE_ECHO flag, or maybe just a NEGATE_ECHO flag that flips the sense of the connection param (in both cases by getting rid of the connectionmaster check and doing it in the attachment)

[mattheworiordan]

If we've got customers asking for it, sure, not hard to add.

Not sure we do, but I think it's something people put up with i.e. echoMessages on / off unilaterally for their connection.

On the flags, I did think about that, and also thought we should provide explicit positive or negative flags that are not affected by the connection preference so perhaps just ECHO_MESSAGES (always on) and SUPPRESS_ECHO_MESSAGES (always off), very similar t what you proposed.

[paddybyers]

I would like to hear about a customer use-case before we start inventing all this complexity ....

[mattheworiordan]

Agreed we need a use case, although having spoken with customers they either enable / disable echo messages completely and work around the fact they can't have both. I don't propose this is done any time soon, but raised the issue as something to consider.

[mattheworiordan]

I would like to hear about a customer use-case before we start inventing all this complexity ....

I think what we should do and would probably negate the need for an echoMessages channel flag in most cases is to support explicit attach flags which we've discussed for a very long time now. @paddybyers is any of this functionality potentially available now with the channel refactoring you have done?

The use case for publishers who are not subscribers is a common one, and we typically recommend customers "hack" their clients by disallowing subscribe altogether in the API key. That's a nasty hack IMHO.

[SimonWoolf]

@mattheworiordan not sure if I'm misunderstanding you, but publish-only channel attach flags have been supported in realtime since February 2017. See e.g. this test suite. Clientside support is currently a little lacking: ably-js supports them, but no others (apart from the translator, which uses them extensively in the Pubnub adaptor); there's a long-standing docs issue to discuss what the official api should be.

[mattheworiordan]

but publish-only channel attach flags have been supported in realtime since February 2017. See e.g. this test suite.

Yup, I spoke with @paddybyers and he confirmed that.

there's a long-standing docs issue to discuss what the official api should be.

Yup, and that is clearly what needs to be done hopefully soon.

[mattheworiordan]

Related to https://github.com/ably/ideas/issues/407

[mattheworiordan]

As discussed with @paddybyers, it's unlikely we'll do this work because instead we should be focussed on supporting explicit attachment flags when creating a channel in the SDK. This in turn would allow a customer to attach to a channel only for publishing for example, and thus would not get an echo.

[sync-by-unito[bot]]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2826