<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue Comment created on issue 254 <br>

Issue Title: added a limits field to the stream configuration <br>

https://github.com/openid/sharedsignals/pull/254 <br>

<br>

Comment: > > I am still trying to figure out how would the receiver use this value and what change of behavior would it have? > > In case of a PUSH receiver, imo this has no impact as the function of pushing still lies on the transmitter. Receiver will have

 no say what so ever. > > In case of a POLL receiver, this will have minimal impact as well, does this require the receiver to poll more frequently? how would that help? When to poll is receiver's descretion. > > This will not be a knob for backstopping as

 well. > > I think we should punt this and think holistically on what are we solving. > > I see the limits as setting expectations and not necessary as something that the receiver need to do something about. In normal conditions there is no need to the limits

 as there is no build up of events in the queue (beside potential temporary spikes). In all three reasons Atul mentioned, the receiver is behaving abnormally (pausing the stream, not pulling, and not being able to process the pushed events). The limits are

 to set the expectations of the behavior of the transmitter in those cases. If this is purely for the FYI and no receiver behavior change is needed, then why can't we communicate this out of band?

</body>

</html>