Clean the cache file about alfred-workflow

[deanishe]

I'm generally against the idea of creating cron jobs and/or launch agents from workflows for a couple of reasons:

• There's no reliable way to remove them when a workflow is uninstalled or deactivated.
• A user might turn on workflow syncing in Alfred, which would move all the workflows to somewhere in ~/Dropbox and break any launch agents/cron jobs you'd installed.

I see the first issue as being particularly problematic for deactivated workflows. For example, I have pretty much every Pinboard.in workflow available installed, but all but 2 are deactivated. If they were all running cron jobs, however, I'd be hammering the Pinboard API and liable to get throttled/banned. AFAIK, there's no simple way for a workflow to tell if it's active/inactive. For this reason, I prefer launching background scripts when the workflow is run to maintain the cache.

The second issue makes a reliable implementation a fairly tricky proposition. As such, I'd prefer to wait and see if there's a lot of demand for it.

While a first_run flag is something we've talked about, it hasn't been implemented yet.

A more configurable way to clean the cache might be a good idea to include. As with any other feature, it is to my mind mostly a question of how many people would find it useful.

I think adding clean_cache() alongside clear_cache() would be confusing, however: the difference is not at all obvious. I'm also not a big fan of having both include and exclude arguments: the semantics of how they interact is non-obvious.

My preferred implementation would be to add an optional filter argument to the existing Workflow.clear_cache() method that would take a function. The function would be passed each filename and return True if that cache item should be deleted.

Admittedly, that would require more coding from the workflow author, but would also provide more flexibility.

[owenwater]

I didn't know the clear_cache(). Having two similar function is a bad idea and I think about your suggestion and using filter function shall be a better one. I can do the implementation in the next couple days.

For automatically calling the clear_cache(). I don't like cron neither but just list it as an option. For the flag option, We can put it as Features to Consider same as first-run().

[deanishe]

Yeah, Workflow.clear_cache() is the underlying function of the workflow:delcache magic argument, which is primarily intended for debugging purposes/resetting the workflow (it deletes everything in the cache directory).

It's not explicitly mentioned in the User Manual.

No reason it can't be called by a workflow itself, though, and I think adding an optional argument to allow finer-grained cache deletion wouldn't overly complicate the API.

Really not a fan of cron jobs, though. Launch agents would be a much better solution to the same problem (no need for a complicated crontab parser), and the agent(s) could be named after the bundle ID, making managing them far easier.

[deanishe]

Featured added in PR #49