search

kutuluk / loglevel-plugin-remote

A loglevel plugin for sending browser logs to a server
MIT License
102 stars 36 forks source link

Multi-messages sending #10

Closed kutuluk closed 6 years ago

kutuluk commented 6 years ago

@Looooopy I have an idea to make sending multiple messages at a time. And use the option "suspend" as the interval for the accumulation of messages in the queue between sending. This will reduce the load on the server. You need it?

Looooopy commented 6 years ago

Sounds like a good idea!

If you do it like an option so users could pick the size by them self so its possible to send a single message in a chunk then i think it would be nice.

One thing to think of when using this feature would be: if a user decide to reload the page this queue will be lost, so the the designer of the site needs to know how many messages he thinks is ok to lose in this circumstances.

kutuluk commented 6 years ago

One thing to think of when using this feature would be: if a user decide to reload the page this queue will be lost, so the the designer of the site needs to know how many messages he thinks is ok to lose in this circumstances.

When the page is reloaded, the queue will be lost in any case. To prevent this, we must store the queue in a persistent storage (e.g. Web Storage). But this is a completely different problem and it needs to be solved separately.

Looooopy commented 6 years ago

Yeah agree but it would be nice to document it.

kutuluk commented 6 years ago

Documentation is a problem for me =(

kutuluk commented 6 years ago

@kristofferahl @Looooopy

I changed the behavior when the queue is full: https://github.com/kutuluk/loglevel-plugin-remote/commit/b2371041c56c12df0a90bdca1b58e776e0d3a3e7

To what extent was it necessary that when the queue overflowed, the old messages would be dropped? The point is that if you drop new messages during a queue overflow, then the algorithmic complexity decreases, the code becomes more concise and the performance increases. Therefore, in order to implement the functionality you proposed, you need a strong case.

kristofferahl commented 6 years ago

I strongly disagree with this opinion. Clean code is nice and all but this is a totally different behavior. The older a log message gets, the less I care about it. So, to throw away new messages in favor of old ones does not make sense to me. In the event of a longer outage on the log server, I could end up getting yesterdays logs but nothing from today. I would ask you to consider changing the behavior back to drop oldest. Or at least offer this behavior as a setting if this goes against your accepted default behavior.

kristofferahl commented 6 years ago

BTW. Thanks for your great work on this plugin! 😃

kutuluk commented 6 years ago

Thank you. With your permission, I will leave more simple behavior so that it would be easier for me to realize what I had planned. But I will return to this when everything is done.

kutuluk commented 6 years ago

@kristofferahl Easy =) Please test.

kutuluk commented 6 years ago

@Looooopy

If you do it like an option so users could pick the size by them self so its possible to send a single message in a chunk then i think it would be nice.

I already made it possible to specify the size of the queue, which in fact acts as a delimiter for the number of simultaneously sent messages. Or is this not enough and an additional option is needed?