JsonRPC method Re-run

[Garulf]

With this method a plugin could tell Flow Launcher to rerun at a desired interval as long as the result has the rerun method. Similar to Alfred's rerun functionality

It can help with queries that change often and calls that are slow or have partial results.

[taooceros]

Interesting. So it is supposed to be background task?

[Garulf]

Interesting. So it is supposed to be background task?

Basically has The launcher sleep for an interval provided by the plugin. Than reruns with the same query. Displaying any results on each rerun.

While true:
    # display results
    if 'rerun' in results:
        sleep results['rerun']
    else:
        break

[taooceros]

Probably sleep feels weird because it forbid other plugin to run. But scheduling a rerun and wake up launcher is possible.

[Garulf]

Yeah sorry I was on mobile and just wanted to get out the general idea.

Definitely would need to work in a non-blocking way. The user should be able to select what results have appeared so far or close flow launcher entirely stopping the reruns.

[pc223]

Interesting, what are the example use cases of this? 💭

[taooceros]

Sounds great. I will write a implementation proposal later.

[Garulf]

Awesome! Thanks for everything!

[pc223]

This's pretty cool in terms of functionality, but the solution feel a bit hackish (quicker to implement right now but can be annoying later), can we find better solution? 😄

The main idea is we need live result, result that can change content even while user is "choosing" (Ctrl+P/Ctrl+N)

A obivious design is make plugin a long running process,

After that we need a kind of "heartbeat", Flow will polling the plugin process for new content.

@taooceros I remember we have proposal to change the plugins to long running process right? (long running instead of the current one-shot style)

[taooceros]

Yes we do, but haven't had a complete api proposal for that.

[pc223]

Probably we should just try this re-run approach first, seems much quicker to implement, if waiting for a "proper" solution, I think it's gonna takes a long time 😄 early deliver early feedback stuff.

[taooceros]

Proposal

• Let JsonRPCPlugin implement IResultUpdate (Or fire up ChangeQuery)
  • implement IResultUpdate
  • fire up ChangeQuery
• Response Format

{
  "result": [],
  "debugMessage": "",
  "rerun": "an integer indicate delay(0 or -1 represent no rerun)"
}

• Rerun Request Format

{
  "method": "query_rerun/query_update/query_refresh/...",
  "parameter": ["Query Search (should be the same as query)"]
}

• Detail Implementation specific
  • Include ID in request model indicates how much rerun has been run?
  • Use async/await to implement or use Channel to implement the task queue
  • Let JsonRPCPlugin (which is the base class) handles the rerun or let specific implementation to handle the rerun (e.g. PythonPlugin)

[jjw24]

oh yeah lol 👍

[jjw24]

with the implementation, we will need somewhere to show what plugins have scheduled re-runs or currently re-running. we actually need to be very explicit about these re-runs because everything around flow has always been manually triggered with the exception of the automatic update, having the ability to do re-runs could open the door for plugins to do background stuff without the user's knowledge. So need to be very transparent and explicit about the re-runs, especially limiting the scope of the implementation.

[taooceros]

Currently the plan is rerun will stop when user change the query, so it is not a backdoor for background task, but just give jsonrpc plugin a way to update their results.

[pc223]

Currently the plan is rerun will stop when user change the query, so it is not a backdoor for background task, but just give jsonrpc plugin a way to update their results.

I prefer this approach for right now, seems much simpler to implement than a long running background process. Although the long running process can be cool in the future.

[jjw24]

rerun will stop when user change the query

oh ok, sounds good

[deefrawley]

I understand the concept here, but it seems like a major change for limited use cases. With Flow, it all happens with the query window - what task would users run there, and wait for updated results without letting the query window lose focus, where they wouldn't simply fire up a browser or dedicated app to handle this better?

[deefrawley]

I've actually thought of a way to use this. I played around with the psutils python library to do a quick system stat plugin (OS, disks, RAM and usage, CPU and usage) but to get the CPU % you need to make at least two calls to the function so it can measure between the two times. Plugin rerun achieves this and gives you live system stats so you could start a process, open Flow and keep an eye on things as it ran.

[taooceros]

Another example is the ProcessKiller plugin, with this feature, we can have CPU%, MEM%, IO rates, network rates,... "dancing" while users choosing process to kill 💀 😄

Actually, C# plugin do support this feature currently. So we can implement this feature directly to it.

[Zeroto521]

we can have CPU%, MEM%, IO rates, network rates,...

These things are status, long-lived application. Flow is a launcher that is used after called, short-lived application.
This is not a good example.

[jjw24]

i personally think it's fine, there should be no constrain on the things that flow do should be launcher only. There are times i would like to see the battery percentage, cpu usage, memory etc in flow and having them on the status bar is one way but seeing them in the launcher is another way.

[Garulf]

A good example would be a process killer. The plugin could show memory/CPU hog's and with "live" information the user can better determine which process to kill.

[pc223]

Try out the current implementation of @taooceros here #648