[Proposal] Re-export config in v4 and synchronize main thread config and worker config

[peaBerberian]

In the RxPlayer team, we very often have to debug devices presenting some type of issue.

What we do usually is to create an RxPlayer branch (through git), push that branch to GitHub, then find a way (sometimes it's not so simple though) in the application in question to rely on the branch (we try to avoid pushing builds on GitHub, so we often rely on e.g. postinstall tricks to build the player in that application when installing / updating its dependencies).

Yet, having to dive into the application's CI / dependency system / build system is no fun and often breaks.

Diagnostics often follow similar RxPlayer code modifications, so I'm wondering if we could not bring back an idea we had in the v3 era:
The idea is to expose through an experimental export our global configuration, to allow updates of the RxPlayer config properties inside that application. Then we could add that custom logic inside the RxPlayer code and only enable it when a config property is enabled.

Config properties is not defined in the API, are comparable to globals (they don't need to be communicated at the function-level) and as such adding custom behavior based on config updates is relatively simple to do.

For example, for the now frequent need when debugging new devices of only loading segments once we now they are decipherable, we could just add in the target application (or even ask them to add temporarily):

import RxPlayerConfig from "rx-player/experimental/config";

RxPlayerConfig.update({
  LOAD_SEGMENTS_ONLY_IF_DECIPHERABLE: true,
})

Because in multithreading mode, we might have to synchronize the main thread's config to the worker's config, I also had to add some synchronization code. It is in essence the exact same problem than for our logger, so I kind of repeated the same logic here.

[Florent-Bouisset]

Editing this configuration is only for debugging purposes, right ?
What I understand is that It's not intended for application developers to edit the configuration. Instead they should use the API to change the behavior rather than editing the config. For example, they should change loadVideo.requestConfig.timeout rather than changing DEFAULT_REQUEST_TIMEOUT.

So, if there is an option like LOAD_SEGMENTS_ONLY_IF_DECIPHERABLE that may provoke undesirable side effects,
and that applications developers are very likely to edit such an options, we should consider of making it part of a documented API ?

Apart from that I'm fine with the code

[peaBerberian]

What I understand is that It's not intended for application developers to edit the configuration. Instead they should use the API to change the behavior rather than editing the config. For example, they should change loadVideo.requestConfig.timeout rather than changing DEFAULT_REQUEST_TIMEOUT.

Yes

So, if there is an option like LOAD_SEGMENTS_ONLY_IF_DECIPHERABLE that may provoke undesirable side effects,
and that applications developers are very likely to edit such an options, we should consider of making it part of a documented API ?

I'm not sure I follow.

The idea here would be to open the way for config properties which are not intended to be in the API yet would be useful for debugging matters only.

If it turns out we have to add this to the API, we would be adding this to the API instead.

A third way which I'm experimenting in some PR right now is to have an experimental object in loadVideo / constructor for future API we're not yet sure whether they may be pertinent or not (e.g. experimental.enableResolutionChecks loadVideo option).

So:

• config properties for things that are not in the API yet allows quick debugging. E.g. forcing all EME steps to start back from the beginning on a problematic device, pre-testing other ABR parameters in a particular scenario, asking a partner to retry reproducing an issue without multi-period support etc.

• API properties only when we decide to add this as a configuration in the API. With the possibility to even bring experimental options for things we're not sure about yet

[Florent-Bouisset]

Ok, thanks for the explaination, got it!