How should Alfy change to accommodate the new Alfred Gallery?

[Jeff Byrnes]

The makers of Alfred have launched the new Alfred Gallery.

It specifically calls for the removal of OneUpdater and, I presume, other auto-updating, in favor of updates flowing through the Gallery.

Any thoughts around this, and how Alfy might lean in to publishing to the Gallery?

[Vítor Galvão]

To clarify, there’s no problem with the library having auto-update capabilities, as long as the workflow submitted for the Gallery does not update itself.

For example, you may have a workflow which you’ve made for your inner circle of friends that wouldn’t be a fit for the Gallery’s general audience. Having the ability to independently send those updates makes sense. It would only be an issue if the Gallery and the workflow were both trying to update. Downloading external code to execute is also a no-go, explained in the link you posted.

In other words, it’s fine to submit a workflow for the Gallery which includes Alfy, just disable (or don’t enable, I guess) its internal auto-updating functionality. Worth noting I’m not intimately familiar with Alfy; if its auto-updating is something which happens automatically for example, that’s a case to be discussed.

OneUpdater is the odd one which has to be entirely removed¹², because it was built specifically to only update³. One of its design goals was to be a single stand-alone object you could add and easily remove from your workflow. It is one object which does one thing (updating) well, hence the name.

Footnotes

1. As the creator of OneUpdater, I’m the first to say it makes sense. ↩

2. Unless, naturally, in the example above where it’s a non-Gallery workflow. ↩

3. Thus there’s no point in having it in the workflow if it’s never called. ↩

[Jeff Byrnes]

Makes sense, thanks for the excellent explanation!