MMM-Scenes2

sdetweil

But that mechanism is somehow annoying for me, so I ignore those methods

what could be annoying… they call, you set a flag.
you save any timer handle when u start it anyhow…

so on sleep you stop it, and on resume you restart the timer… what could be so hard
if you get data back while suspended, you don’t call updateDom(), and don’t restart the data request

tiny amount of code…

mumblebaj

@sdetweil and @MMRIZE Thanks for the useful information.

MMRIZE

@sdetweil

what could be annoying… they call, you set a flag.

It may be a relative point of view.

Let’s assume my module is using a paid API that has a daily quota. To save the consumption API quota on unused time, it would be better to suspend/resume the process of the node_helper(usually node_helper takes a charge to consume API)

However, some API needs an expensive re-establishment fee for their usage. For example, some Google APIs might have short valid lifetimes of retrieved tokens and data. So, it needs to begin with handshaking again at some point. It may require the additional cost of the connection/auth/indexing process. If some 3rd party module tries to resume/suspend my module in a habitual rapid cycle, It might be another abused waste of consumption and, even worse, unpredictable.
I said this would be annoying for me.

Of course, I might also be able to manage the lifecycle of resource consumption, but I think it is not worth it, at least based on my experience with MM modules. (Yup, I’m the one who made most many modules in this scene.)
I prefer background-alive with silence than suspend/resume modules frequently. It is more stable. (at least for me.)

sdetweil

@MMRIZE yes, there can be consequences

mumblebaj

@sdetweil Hence I always warn users of API limitations. if they exceed then it becomes their issue.

sdetweil

@mumblebaj well… not really. the modules mostly don’t recover, the user doesn’t know, and then we waste time trying to debug it. lots of modules don’t report failures in the node_helper either.