New in IDL 8.6: IDLTasks

ENVITasks have been around for a few years now, but they didn’t help those of you who only have IDL and not ENVI as well.  In IDL 8.6 we are happy to announce that the ENVITask concept has been carried over to work in pure IDL without ENVI.  Many of the features are the same, but there are slight differences that I want to point out in this post.

The first and most obvious is how you construct an IDLTask.  Rather than launch ENVI and then call the ENVITask()function, you can call the IDLTask()function at any point in time.  As the help points out, you can pass in either a scalar string that is the name of the task you want or its filename, or you can pass in a Hash object that is the task definition (what you would get if you called JSON_Parse() on a task file).  If you pass in a string that isn’t a filename (relative or absolute), then it is treated as a task name.  The function will then look at !PATH and search for all .task files in each folder listed there.  It catalogs all the .task files it finds, but if there are multiple folders with the same base name only the first is recognized(just like how IDL handles multiple .pro or .sav files with the same base name found in !PATH).  The list of .task files is filtered to those with the correct IDLTask schema, which currently is only “idltask_1.0”.  This way we don’t accidentally pick up an ENVITask files and cause confusion.  If a.task file with the same base name as the requested task name is found, it is used as the task definition.  If no exact match is found, but partial matches exist, then helpful error messages are returned telling you about the name(s) that partially match, so you can correct your code.  I should point out that the current working directory (which can be retrieved by calling CD with the CURRENT keyword) is searched before any of the folders in !PATH, so that can affect the behavior of IDLTask().

The “idltask_1.0” task schema used for IDLTasks in IDL 8.6 is very similar to the “envitask_3.0” schema used by ENVITasks in ENVI 5.4.  The notable exception is that the TYPE property of your parameters won’t understand ENVI class types like ENVIRaster.  But all the basic datatypes available in IDL are supported by IDLTasks – strings, Booleans, and numbers, as well as List, Hash, OrderedHash, and Dictionary.

Another difference is how you interact with IDLTasks on GSF as opposed to ENVITasks.  The service endpoint for IDLTasks will be http://hostname:port/ese/services/IDL,while the ENVITasks use http://hostname:port/ese/services/ENVI.  The different endpoints are used to discriminate between the requests that should use the IDLTask() function vs the ENVITask() function to load the requested task.

Easy GSF deployment is one of the primary reasons you would want to build IDLTasks in the first place. If you have IDL functions or procedures that you are used to calling directly, then you are probably wondering why you would want to wrap them in an IDLTask.  As a C++ developer in a previous life, I appreciated the type safety that C++ requires, so I also appreciate the parameter validation that IDLTasks provide.  When developing your custom IDLTask, you will have to spend some time thinking about what the inputs and outputs are for your code, but once you do that you won’t need to worry about writing lots of input validation code, the IDLTask framework will take care of that for you.  The IDLTasks are also self-documenting like ENVITasks, so if someone else hands you a .task file and .sav file, you can load the task and then learn all about the parameter names, their types, cardinalities, and hopefully even descriptions. All of this information makes it possible to deploy your algorithms on GSF for running in the cloud, with all the same introspection capabilities over the REST endpoint.  Alternatively, you can set up batch processing using some sort of folder watch capability to spawn IDLTaskEngine instances to automatically run your code on each file that appears on your system.