Re: Feature Mod: Add metering, parallelism & throttling options to AddEventListenerOptions

[Sylon Zero]

Sorry, looks like I've posted this in the wrong spot. I will move it to the
WHATWG  group, as recommended.

On Mon, Nov 27, 2017 at 3:49 PM, Sylon Zero  wrote:

> *Core Problem Statement* Processor functions that subscribe to events via
> a topic string may need to be prioritized for processing based on the topic
> itself. Conversely, certain events may be more numerous but should not
> limit the ability of the JS environment to respond and process other
> events, that may be more critical to either the User Experience (UX) or
> integrity of the system (e.g. events that trigger saving data to a
> back-end).
>
> *Background Information* As Browser/CommonJS environments bring paradigms
> like UI event handling and back-end event handling into the same problem
> space, it is useful to apply common patterns used in Message-based
> Publish-Subscribe environments with message brokers, which is what the JS
> execution context often behaves as. The use case here is to ensure that one
> kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
> or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
> massive differences in event volume or conversely, expensive operations
> that block the execution thread in question.
>
> *Proposed Solution* Add metering options to the addEventListener *Options*
>  configuration object. These options control how the JS execution
> environment controls the throttling/firing of event handler instances in
> response to events that match the topic string of the subscription created
> by addEventListener.
>
> Proposed options:
>
>- maxInstances [Number / Function] used to decide how many event
>listeners can be invoked before throttling occurs. Throttling does not lose
>events but simply queues them.
>- throttlingQueueLength [Number] used to maintain an in-memory queue
>of un-processed events per Topic string, after throttling kicks in.
>- throttlingQueuePolicy [String] Values could be exception - throws an
>exception when the queue length is exceeded, rolling - drops the
>oldest events and pushes newer ones into the queue, expand- allow the
>queue to expand to cover all events.
>
> *Additional Options* It might be even more useful if the options allowed
> targeting or creation of Web Workers (or Node child processes, depending on
> the execution context) based on the event handler configuration. This could
> potentially target CPU cores and/or O/S child processes / threads
> (depending on the O/S terminology for parallel execution).
>
> *Related Thread* The proposal identified in the link below (by Šime Vidas) 
> could
> be part of this solution as it defines other metering options around
> debounce (which improves scale around event handling, which is in the same
> problem space) and handling throttling through frequency, which should be
> one of the alternatives in addition to my proposal above (as I believe they
> are orthogonal): https://discourse.wicg.io/t/add-event-throttlin
> g-and-debouncing-to-addeventlisteneroptions/2436/19
>
> Sai Prakash
> @SylonZero
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Mod: Add metering, parallelism & throttling options to AddEventListenerOptions

[Oriol _]

`addEventListener` in not part of ECMAScript. It's defined in the DOM spec. You 
should send your proposal to the WHATWG.

--Oriol
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Feature Mod: Add metering, parallelism & throttling options to AddEventListenerOptions

[Sylon Zero]

*Core Problem Statement* Processor functions that subscribe to events via a
topic string may need to be prioritized for processing based on the topic
itself. Conversely, certain events may be more numerous but should not
limit the ability of the JS environment to respond and process other
events, that may be more critical to either the User Experience (UX) or
integrity of the system (e.g. events that trigger saving data to a
back-end).

*Background Information* As Browser/CommonJS environments bring paradigms
like UI event handling and back-end event handling into the same problem
space, it is useful to apply common patterns used in Message-based
Publish-Subscribe environments with message brokers, which is what the JS
execution context often behaves as. The use case here is to ensure that one
kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate
or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to
massive differences in event volume or conversely, expensive operations
that block the execution thread in question.

*Proposed Solution* Add metering options to the addEventListener
*Options* configuration
object. These options control how the JS execution environment controls the
throttling/firing of event handler instances in response to events that
match the topic string of the subscription created by addEventListener.

Proposed options:

   - maxInstances [Number / Function] used to decide how many event
   listeners can be invoked before throttling occurs. Throttling does not lose
   events but simply queues them.
   - throttlingQueueLength [Number] used to maintain an in-memory queue of
   un-processed events per Topic string, after throttling kicks in.
   - throttlingQueuePolicy [String] Values could be exception - throws an
   exception when the queue length is exceeded, rolling - drops the oldest
   events and pushes newer ones into the queue, expand- allow the queue to
   expand to cover all events.

*Additional Options* It might be even more useful if the options allowed
targeting or creation of Web Workers (or Node child processes, depending on
the execution context) based on the event handler configuration. This could
potentially target CPU cores and/or O/S child processes / threads
(depending on the O/S terminology for parallel execution).

*Related Thread* The proposal identified in the link below (by Šime
Vidas) could
be part of this solution as it defines other metering options around
debounce (which improves scale around event handling, which is in the same
problem space) and handling throttling through frequency, which should be
one of the alternatives in addition to my proposal above (as I believe they
are orthogonal): https://discourse.wicg.io/t/add-event-
throttling-and-debouncing-to-addeventlisteneroptions/2436/19

Sai Prakash
@SylonZero
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss