Open stangri opened 1 month ago
Curious: what's the necessity for the long running process? What does it ensure it achieves? Is it like a big flush operation?
Just to clarify, is the pause
function basically a way to temporarily disabling adblock as the blocklist is moved to somewhere else so the package just assumes to allow everything? Do you need a way then to act on when the timeout (the one from 1 to 60 seconds) completes without blocking the UI in the meantime?
Thank you for your replies.
Curious: what's the necessity for the long running process? What does it ensure it achieves? Is it like a big flush operation?
It may be desirable to wait for up to 60 seconds to make sure that the previously blocked domain name resolves, this, plus two resolver restarts require a long wait.
Just to clarify, is the
pause
function basically a way to temporarily disabling adblock as the blocklist is moved to somewhere else so the package just assumes to allow everything?
Yes, blocklist is moved and resolver is restarted to essentially remove the blocklist from operation. After the timeout the blocklist is placed again somewhere where resolver will pick it up and resolver is restarted again.
Do you need a way then to act on when the timeout (the one from 1 to 60 seconds) completes without blocking the UI in the meantime?
I think it would be OK to block UI for the period of the time out and I can load the time out length variable so, ideally the countdown is displayed within the modal window.
If there's an option to block the UI for the duration of timeout (plus resolver restarts), the UI doesn't need to be refreshed afterwards.
How about a sleep operation in a ucode script when handling these? It seems much better suited to run the operations on the local device.
@systemcrash if I understood you correctly -- the rpcd code is not an issue, I already have it, my issue is how to handle the 60 seconds long request from the javascript/luci app.
Yeah, I might eventually come up with a solution, but long running operations require the client to continually poll the HTTP endpoint. So maybe a 302 redirect would work. Is there a way to forcibly empty caches of the resovler so a more immediate restart would work?
Sooo..... another idea might be to do what happens when the config is applied. We have a 90 second count-down until we get an "all-clear". Maybe utilise something like that?
Either co-opt the function or create your own?:
Either co-opt the function or create your own?:
Sorry, I may need some help understanding how can I use this. Isn't ucode the router-running piece of code? I do have the RPCD call working, I need help figuring out what type of javascript code needs to be implemented to support a long-running rpcd call.
Yes, uci runs on the router.
Does the 'pause' action have any kind of return or timeout? Reimplement the apply function above (in a .uc script) called like pause_await
, and have this exported function call your rpc 'pause' function that returns after the necessary 60 seconds. Then your new e.g. pause_await
routine responds after the allocated 'timeout'.
You might call this pause_await
from the JS page by defining a pause_await
function triggered by the pause
button on the page. Compare with how e.g. apply
is implemented here when you apply the config.
Hey @systemcrash @dannil, seeing your efforts to convert lua apps to js apps, I wonder if I could solicit your help with luci-app-adblock-fast.
The principal package has support for the
pause
function which (with one command as opposed to stop, then wait, then start) moves the resolver's blocklist file to a temp location, restarts the resolver, waits (from 1 to 60 seconds) then moves the block-list back and restarts the resolver again.I've struggled to implement it in the luci app due to the time-outs. I have the rpcd call implemented but I don't know how to properly handle long waits for the return from the call in the luci app, any ideas?
Thanks!