Allow Script Filters to Refresh Results

[canadaduane]

Looking through past posts, it looks like many of us workflow developers are encountering a similar problem: how do we both [a] respond quickly to user input and send results to Alfred, and load data from slow external sources that we depend on to show results to Alfred.

 

Here are several discussions about this topic, from different angles:

 

 

Displaying Items As They Echo

http://www.alfredforum.com/topic/228-displaying-items-as-they-echo/

 

Refresh script filter xml after first echo

http://www.alfredforum.com/topic/222-refresh-script-filter-xml-after-first-echo/

 

Refresh workflow

http://www.alfredforum.com/topic/215-refresh-workflow/

 

Workflow script filter with one-shot completion

http://www.alfredforum.com/topic/142-workflow-script-filter-with-one-shot-completion/

 

Ability to buffer input for script filters (Wait until user is finished typing before calling script)

http://www.alfredforum.com/topic/91-assorted-feature-requests/

 

 

I think that the best solution proposed so far is tomhunt's: allow the xml to be replaced by new xml later on in the script execution, or in other words, allow script filters to resend the results to Alfred as many times as desired.

 

This seems to solve the problem neatly in several ways:

1. If scripts have local storage with cached results, they can immediately send a preliminary list to Alfred.

While the script is working in the background to retrieve data from the internet, other keypresses can still re-execute the script for updated cached results Once the script has retrieved its data from the internet, it can again push a final list of results to Alfred. For scripts that have partial information at first (such as cached names or IDs of items) and later get data from one or more internet requests, the results list can be updated as desired to reflect new information.

Duane Johnson

http://makerhome.ca/

[jdfwarrior]

Duane,

 

When requesting remote data, results or data doesn't come back a little at a time. It's typically that you make a request and all the data is pushed back in one lump. That being said, why make Alfred refresh the list several times? It's not coming in a little at a time, you already have it all. The only time you MAY would want something like this would be if you were requesting data from multiple remote data sources. 

 

Local script data is typically going to be available so fast that loading the data incrementally wouldn't make much sense.

 

I can see your point for mixed data where you could be returning local and remote data but I would think that most people won't be providing such workflows. 

 

Returning multiple lists also would require a decision as to how the state of the list is going to be stored. I would think that Andrew wouldn't want to have to hold that and merge within Alfred. That being said, it would be the developers responsibility to get some data, convert to xml and keep the original data, return that, get more data, merge that data with the original, and convert to xml again, repeat. I really don't see where it would be that advantageous.  Andrew did recently add the "Please wait text" into workflows that will allow you show the end user that the workflow is still waiting on feedback from the script filter. As cool as it sounds to be able return the data the way you're talking about, I really think Andrew chose the best option for us.

[canadaduane]

When requesting remote data, results or data doesn't come back a little at a time. It's typically that you make a request and all the data is pushed back in one lump. That being said, why make Alfred refresh the list several times? It's not coming in a little at a time, you already have it all. The only time you MAY would want something like this would be if you were requesting data from multiple remote data sources. 

 

My use case:

 

I have a *partial* local store of "issue tickets" as well as a *complete* remote store of tickets. When the user types "ticket <search term>" I want to be able to show tickets that have previously been cached in the local store. A "cache hit" is a likely scenario: users often search for tickets that they have previously visited.

 

However, it isn't good enough to only show tickets in the local store IF there are further matching terms, OR there have been remote updates to tickets previously cached locally. Therefore, I would like to show an initial list of matches, followed by an updated list of matches. (The list of matches may contain the same number of items, but with updated titles, OR the list may increase or decrease in size).

 

Local script data is typically going to be available so fast that loading the data incrementally wouldn't make much sense.

 

Agreed, it doesn't make sense for local data retrieval.

 

I can see your point for mixed data where you could be returning local and remote data but I would think that most people won't be providing such workflows. 

 

I think the above list of people seeking a solution shows that many people are looking for something not optimally handled by Alfred at the moment.

 

Returning multiple lists also would require a decision as to how the state of the list is going to be stored. I would think that Andrew wouldn't want to have to hold that and merge within Alfred.

 

I won't speak for Andrew, but I can imagine several ways where this could be done efficiently. The most obvious is just to keep the selection at the same place in the updated list as where it was in the previous list (i.e. using the uid to match item identity). Otherwise, just replace the old list with the new list. No merging involved (i.e. the only state held between updates is the uid of the selected item).

 

That being said, it would be the developers responsibility to get some data, convert to xml and keep the original data, return that, get more data, merge that data with the original, and convert to xml again, repeat. I really don't see where it would be that advantageous.  Andrew did recently add the "Please wait text" into workflows that will allow you show the end user that the workflow is still waiting on feedback from the script filter. As cool as it sounds to be able return the data the way you're talking about, I really think Andrew chose the best option for us.

 

I'd like Alfred to be a little snappier in spite of possibly slow server response times

 

Duane