raguay.customct Posted May 1, 2014 Share Posted May 1, 2014 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. Link to comment Share on other sites More sharing options...
rice.shawn Posted May 1, 2014 Share Posted May 1, 2014 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. Link to comment Share on other sites More sharing options...
raguay.customct Posted May 1, 2014 Author Share Posted May 1, 2014 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! Link to comment Share on other sites More sharing options...
rice.shawn Posted May 1, 2014 Share Posted May 1, 2014 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. Link to comment Share on other sites More sharing options...
raguay.customct Posted May 1, 2014 Author Share Posted May 1, 2014 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. Link to comment Share on other sites More sharing options...
rice.shawn Posted May 1, 2014 Share Posted May 1, 2014 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. Link to comment Share on other sites More sharing options...
deanishe Posted June 7, 2014 Share Posted June 7, 2014 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now