External Trigger - Add Callback function

[raguay.customct]

I am exploring many ways to use this great new feature. Some cases, I would need feedback from the trigger call. Could you add a call-back function to define a callback shell script? I am adding ways for my custom web server written in go to interact with Alfred, but I need the callback to make a complete solution. Maybe extend the AppleScript to:

 

tell application "Alfred 2" to run trigger "timer" in workflow "com.customct.Timer" with argument "test" with callback "~/bin/callback {query}"

 

The {query} macro would get expanded with what the final stage of the external trigger produced. Therefore, if the external trigger connected to a Run Script block, the result of that block would get returned to the callback in the {query} macro.

[rice.shawn]

I was just about to request this. I actually just tested it with a script filter, hoping that I would just get the XML, but it called Alfred instead. Another option, instead of defining a callback would just be to redirect STDOUT back to the applescript so that we can capture whatever text it produces in an applescript variable. That would be a fine middle ground.

 

On an cool note, now we can have script filters that can be called without key words. That's pretty damn cool and potentially useful.

[raguay.customct]

I would prefer the call back approach since the external trigger could take an undetermined amount of time. Much more like the JavaScript programming paradigm that I am used to. Internally, I believe the callback approach would be less taxing on Alfred as well. Truthfully, the less I have to do in AppleScript the better!

[rice.shawn]

I agree on both accounts, but my assumption is that redirecting STDOUT would be easier to code (and thus get this feature to us faster).

 

Ideally, we'd have both because they each have their value. Redirecting the STDOUT would be particularly useful if you want to grab the results while in a workflow to use in that workflow.

[raguay.customct]

Actually, the two are not mutually exclusive. If no callback is defined, then the redirect STDOUT would be done. Otherwise, the callback route would be done. The callback gives the flexibility of just calling a command line program with set parameters as well and not a full script. It is amazing what you can put in one command line! If you did not want the output at all, then the callback could just do nothing. That way the AppleScript would not have to wait for completion to continue doing things.

[rice.shawn]

Touché.

 

And, yes. It is amazing what you can do with the command line. Alfred's current existence is a testament to that very notion.

[deanishe]

I would prefer the call back approach since the external trigger could take an undetermined amount of time. Much more like the JavaScript programming paradigm that I am used to. Internally, I believe the callback approach would be less taxing on Alfred as well. Truthfully, the less I have to do in AppleScript the better!

It wouldn't be less taxing on Alfred because you could end up with an indeterminate number of (Alfred) threads running in the background due to the asynchronous behaviour of the API and dumb apps/workflows making loads of calls to Alfred before the previous one has completed (async is very hard to get right).

There's no reason the entire Alfred process has to block while processing your call—it already calls workflows in parallel—but that API call should, imo, be synchronous and block until the output is ready to be returned or an error occurs (which should be returned via the same route the input came in).

If the caller needs to continue doing other stuff while Alfred's busy, it's simple enough to start a thread in a synchronous process, and any asynchronous framework worth its salt already has the capability to deal with calling out to external, synchronous processes (it's just another form of IO).

Sending the output to an entirely separate external process (as in your example) strikes me as a bad idea (as an API), unless you don't care if the call succeeds or fails.

If an error occurs and there's no communication back to the caller, it has no way of knowing if its call to Alfred is just taking a long time or the call failed and there is something wrong/the call should be retried (not that Alfred has yet provided a way for a workflow to know if it's succeeded or failed). Similarly, if the call is taking too long, a caller that still has a connection to the process its calling can terminate that process (Alfred could, for example, terminate the relevant thread(s) if the calling process closed stdout/stderr) and try again.

At any rate, it should not be called "callback"

Edited June 7, 2014 by deanishe