HubLifetimeManager clean-up

[analogrelay]

• Consolidate primitives down to a simple "group"-like primitive. Users can be implemented via that rather than being their own primitive.
• Consider reducing the number of separate channels. Some things could be handled simply by using different payloads on the same channel. Example: All/Group Except could share the standard channel and all invocations could have an optional ExcludedIds.

[analogrelay]

I do have a proposal, bringing something retro back to SignalR Core: Signals.

HubLifetimeManager would basically have three APIs (excluding connection lifetime APIs): InvokeSignal, AddToSignal and RemoveFromSignal. Every connection ID would automatically be a signal, as would each group and user. Some namespacing would be needed (we could either use string mangling or have a SignalName type that actually has a little structure to reduce string comparison in some cases). InvokeSignal would take a list of connections to be excluded from the invocation (which can be empty).

That one primitive (Signal) should be able to handle all the cases we have today.

[mikaelm12]

Whats the proposed timeline for this change? Seems like a lot of churn which is both an argument for and against getting it into preview 1.

[analogrelay]

I don't think we'll be able to do it in preview 1. There are design considerations to discuss here. It's a low-traffic API (in that most users will never see it) so it's reasonable to make changes to it in preview 2.

[analogrelay]

We can also implement .MultipleClients(...) via having a Signal with no members (a Null Signal) and adding support for invoking "Signal + Additional Clients" or by just allowing an "Invoke Multiple Signals" primitive.

[mikaelm12]

We're deciding against this. Sorry @anurse