Not sure if it makes sense in the DTP logic, but it would be great if “add download” returned a record instead of a boolean. Ideally the record would include a “loading” property similar to a tab.
If “add download” returned a record it would allow an existing parent record to be associated with the download record at the time the “add download” was executed. At the moment I’m having to take convoluted route of trying to match records of downloaded items to their parent by matching URL. Its not working to well.
The command just adds an item to the download manager which might or might not download the item to the database (or just to a folder), maybe soon, maybe never. Therefore such a revision is not planned. Maybe the command download URL would be more suitable for your scripts?
Point accepted. But from a scripting perspective its great that you provide the “add download” function, but then its odd a bit odd that programatically you then struggle to do much with it as you’ve lost the relationship to the download job.
Anyway, thanks for the feedback. I’ll try the “download URL” again. My challenge with this was the original URL doesn’t specify the filename. so calling “download URL” just returns the data. I’ve no idea what the actual file is called or its kind. I’ll figure something out.
It looks a bit inconsequential, agreed. As if an asynchronous call is missing a callback function or a completion handler. Which is, otoh, understandable, as Apple’s scripting engine is so old, it doesn’t allow for this kind of concept.
But you could, of course, use the URL you pass to addDownload later to find the corresponding record. Maybe not from a script run inside DT, as that would block the app, but from osascript. If you are using JavaScript, you could for example wrap your addDownload call in a setTimer to check for the existence of a record with the URL after some time.
Agreed again – it would be useful if the downloadURL method returned the MIME type for the response. But then, everything is written for AppleScript, and returning two values (MIME type and the data) is probably awkward.
I suggest using doShellScript(`echo "${data}" | file -Ib - | sed -e 's/^.*://' -e 's/;:*$/'`)
(that’s in JavaScript, in AS you’ll have to take care of quoting). That writes the string returned by downloadURL to the stdin of the file command, whose output is then processed by two sed replacement commands so that only the MIME type remains. That will give you, for example, application/pdf or image/jpg or text/plain.
However, this approach may fail if the downloaded data is too large. In that case, your best bet is to save it to a file outside of DT using the methods provided by StandardAdditions and then pass that file on to file as shown above, replacing the - by the actual file name and omitting everything up to and including the first pipe symbol. And then remove the file.
That’s not the issue (as this is possible) but it’s not the intended job of the download manager. Downloads can be started & stopped, not all or even none of them will end up in a database, the app could be quit and launched again etc. For scripting there are other possibilities like the already mentioned command.