Currently, EventLogging defines its transport using navigator.sendBeacon with a fallback to an image beacon. Recently T225578: EventLogging needs to enque events to avoid draining users' battery on mobile have developed mechanisms for queuing requests, allowing them to be sent in bursts. This patch is interesting because of how it tries to make its mechanism rather generic.

It has been mentioned by @pmiazga in relation to T235189: Develop small client-side error logger for MediaWiki that it would be useful for debugging purposes to allow some form of dependency injection for the output, so that, e.g. a console or other output format/mode could be specified, rather than HTTP POST. A similar argument will likely apply for debugging and testing of analytics events.

On the app platforms, it has already been noted that the transport is often delegated to a network manager of some kind that buffers and times all HTTP requests from the application. In this scenario, it is likely that the analagous EventLogging library will delegate both the output buffering functions and the actual output function (sending an HTTP request, etc.) to some external code.

Because we want to evolve these APIs together, we should perhaps investigate how to achieve some of this after the current patches for EventLogging get merged.