[Proposal] add LogFormat static property

[peaBerberian]

A large amount of time spent when maintaining the RxPlayer is actually spent on debugging device-specific issues.

Consequently, we beefed-up our debugging capabilities: we added a LOT of logs, developed our own specialized remote
debugger so we can be monitoring low-end devices for a long amount of time (unlike chromium's or webkit's debugger), added the DEBUG_ELEMENT feature, developed some reverse-engineering tools as well as (closed-source) visual logging tools.

Now that we have many tools at our disposition, I see that our regular logs (that can e.g. be produced by calling RxPlayer.LogLevel = "DEBUG") - the most relied on way by application developpers - are lacking.

The most evident lacking data is some kind of timestamp, to better understand time-related issues, which are frequent.

But more than that, there's a lot of comfort in being able to rely on our aforementioned RxPaired remote debugger, so I was wondering if we could allow the production of logs in a format that could be easily imported by it.

Hence the idea of a supplementary RxPlayer.LogFormat property. It is by default set to "standard" - which is the currently-existing format, but can also be set to the RxPaired-compatible "full" format which:

• Immediately produces the [Init] log, which today only serves to provide a way to convert between date representations (date on the device or monotonic timestamp since the page was opened) inside RxPaired (and also ultimately perform protocol version detection).

• Prepend each log with a timestamp and the "namespace" of the log (e.g. [error] for error logs).

Here, we could tell application developpers not only to call:

RxPlayer.LogLevel = "DEBUG";

But also:

RxPlayer.LogFormat = "full";

When the idea is about communicating logs to us (if they just want to display logs for initial debugging steps of an issue potentially on their side or the content's side, the "standard" format may be clearer to them as less verbose).

Thoughts?

[peaBerberian]

Note that with this solution there's a risk of double formatting on RxPaired's side when both LogFormat = "full" is set and RxPaired is enabled.

There's not a lot of reason in doing that however.

Maybe we could at worst handle explicitly that case in RxPaired's inspector (and perhaps server) side?
(Of course the most logical would be to do so in the client but I like the idea of it staying as dumb as possible and to still just send prefixed logs - which here do contain information we already can know)

[Florent-Bouisset]

Note that with this solution there's a risk of double formatting on RxPaired's side when both LogFormat = "full" is set and RxPaired is enabled.

There's not a lot of reason in doing that however.

Maybe we could at worst handle explicitly that case in RxPaired's inspector (and perhaps server) side? (Of course the most logical would be to do so in the client but I like the idea of it staying as dumb as possible and to still just send prefixed logs - which here do contain information we already can know)

Yes, we could imagine that the RxPaired client can also use the RxPlayer.logFormat = "full" instead of patching the console in its client code. This will only work for version >= 4.2.

[peaBerberian]

Yes, we could imagine that the RxPaired client can also use the RxPlayer.logFormat = "full" instead of patching the console in its client code. This will only work for version >= 4.2.

But that would mean that you could have no way of having standard RxPlayer logs in the console AND RxPaired running, which could be wanted (or not)?

[Florent-Bouisset]

Seems good to me, maybe in the future we could also create a github template for issue and mention to set logLevel and logFormat when recording logs

[Florent-Bouisset]

no

Ok I understand, maybe this was not a good idea because we could not have different log format in console and rxPaired