Support buffer usage in Subscriber state?

[AravindaDP]

It seems currently SubscriberState only supports unbuffered usage of ProxySubscriberCached. So it's only possible to get the latest message as of State execution. If there were additional messages received between two state executions of SubscriberState those messages will be lost.
Is it possible to extend the SubscriberState to support buffering with a additional State parameter to enable it? Or is this beyond the scope of design of SubscriberState and best implemented as a seperate State?
If this enhancement is something welcome enhancement to SubscriberState, I would like to give it a try to jot down a PR.

[dcconner]

A few contradictory thoughts:

Is it possible to extend the SubscriberState to support buffering with a additional State parameter to enable it?

It is possible. I'd have to look at details so I welcome a proposal.

If this enhancement is something welcome enhancement to SubscriberState, I would like to give it a try to jot down a PR.

Contributions are welcome.

I think we'll need to look at the details of how complex the change is. Presuming a new parameter that defaults to the current behavior should be OK. The question will be how messy the logic needs to be. I presume we just have option for single user data as now, or a tuple of one or more points as output. The trick is that the state returns on receipt of message. So unless you have high rate points you probably won't get many in one update step; so almost always you'd be getting a list with one point. That seems to be overly complex.

If you do have high rate points, then you'll only capture a small fraction of them with this state, and I wonder if a different design might be better. Say if you wanted to collect X number of points. At that point, I'd think a new state would be better as it is departing from the specific function of subscriber state.