GetURL revisited

I’ve been dabbling around with ExtendScript DLLs.

These little critters run within ExtendScript and allow me to enhance ExtendScript, for all apps that support it, including InDesign Server, on Mac and Windows.

I can add whatever functionality I decide to wrap into such a DLL.

Now, I’ve just finished wrapping the C++ libcurl into such a wrapper. A full version can be downloaded here (runs till December 31, 2020. A new binary will be provided around December 1):

https://www.rorohiko.com/downloads/JSXGetURL.0.0.4.zip

There is nothing to install, no admin privileges needed. You just need to add a folder with a few .jsx files to your ExtendScript project, and you can simply write ExtendScript like:

#include "JSXGetURL/JSXGetURLLoader.jsx"

var getURL = JSXGetURL();

var s = getURL.get("https://www.rorohiko.com");

alert(s.substr(0,1000));

and this works in InDesign Server, ExtendScript Toolkit, Bridge, InDesign, InCopy, Illustrator or whatever else supports ExtendScript, and it works both on Mac and Windows. And it’s very fast because it’s all compiled C/C++ code.

(Note: when running from ExtendScript Toolkit make sure that the Debug – Do Not Break On Guarded Exceptions menu item is ticked. The loader relies on try-catch to work when it figures out whether to load the 64-bit vs 32-bit dynamic library).

Right now, I’ve only done a synchronous get and post and nothing event-driven. I can add many bells and whistles, as desired; I’ve done only a proof-of-concept.

As it is, this thing now kind of supersedes my old ventures (https://coppieters.nz/?p=133 which uses CEP/node as a ‘servant’ to ExtendScript, and does not work on InDesign Server, and https://rorohiko.blogspot.com/2013/01/geturlsjsx.html which was pure JSX, a subset of http only, no https).

For commercial use, I am currently thinking of the following approach:

  • Make this binary ExtendScript enhancement available free of charge.
  • I’ll refresh/update the ‘free’ binaries every year around December.
  • I am open to negotiating support contracts for anyone interested. These support contracts can be tailored to provide developer training, assistance with compiler setup, creation of custom versions, access to the source code and compiler IDE files…

The conundrum I was facing: what to do with this? Over the years, I’ve tried to ‘productize’ some of the software I wrote, but I’ve never managed to generate enough income from that to make it worthwhile. My main income is always from consultancy/custom dev/project kickstarts/teaching/temporary team booster.

As a potential ‘shrink-wrap’ product, this one is even more problematic. I think the market for this product is extremely limited (maybe 10-100?). And ExtendScript is on the way out, so the lifetime is limited. Productizing it (adding licensing/demo/docs/support/marketing…) would be a fair bit of effort. Coding is just a small part of the whole product creation.

But I think this could be extremely helpful for a bunch of InDesign Server projects (and maybe for some Illustrator and Bridge projects). Being able to ‘grab’ assets straight off a URL via a lightning fast C/C++ DLL is pretty powerful.

For example: how about protecting your intellectual property by dynamically loading part of your critical code from a remote server after a license check, instead of relying on JSXBIN?

The next thing I want to try is to embed a Chrome V8 engine inside ExtendScript – turn the world on its head. There is no business case for this – it’s just something I want to try and see how it works out.

Having V8 inside ExtendScript would allow me to keep the ExtendScript DOM and run modern JavaScript – have my cake and eat it too.

Anyway: if you’re interested in this ExtendScript enhancement and have ideas or questions, contact me at [email protected]

11 thoughts on “GetURL revisited”

  1. Sounds very interesting.
    Would it need to be recompiled for each version of InDesign, and separate versions for Mac/Windows?
    Would it be able to download a graphic file and place it into a document?
    Ariel

    1. No need to recompile, and the same set of files should work across all versions of Adobe apps. And there are no separate versions for Mac/Windows. In fact, there are, but both Mac and Windows (both in 64 and 32 bit) are included in the release, so you get a single, self-contained folder that has everything it needs. The same folder works on Mac, Windows and any reasonably recent version of the CC apps.

    2. And yes, it can download a graphic file. You first download, then use ExtendScript …place() to place it. That also works with ExtendExtendScript and the old GetURL() functions I wrote long time ago.

    1. It’s just a string. To write it out correctly, you need something like (from memory):


      var f = new File("...");
      f.encoding = "BINARY";
      f.open("w");
      f.write(s);
      f.close();

      and that works for writing out binary content in strings.

    1. Yeah, I intend to fix that in a more capable version later on. I found that the ES-to-DLL API does not support non-null-terminated strings. Binary strings in ES are fine, but the API does not allow them to pass through 🙁

      So, the current alpha version has an optional file path param in the JSXGetURL.get() function to download straight to file.

      Later on, I’ll provide access to the HTTP headers with an enhanced version of JSXGetURL, which will allow you to check for the contentType. At the moment, all you can do is check the file name extension (if there is one), or inspect the downloaded content and do some smart recognition (which is not hard to do for the common image file formats).

  2. Hello, Kris. I tried it, with the sample file zipped and received an error when hit run. ESTK opens the JSXGetURLLoader.jsx and marks line 85 saying “I/O error” in statusbar. Is this something I’m making wrong?

    1. Make sure you have ‘Do Not Break On Guarded Exceptions’ selected in the Debug menu. The loader uses try-catch to figure out what to load (32 bit vs 64 bit). As 64 bit is most common it tries that first. ESTK is 32 bit so it will first throw on the 64 bit load, and then try the 32 bit version.

      Could that be the issue?

  3. Hello Kris,

    you’ve done a nice job, congrats !

    I’m looking for a way to upload files to HTTPS servers from an inDesign server on Windows. No way to use native Socket object so I was thinking I could use app.doScript with some VB (like this : https://github.com/grefel/restix/blob/master/restix.jsx) but when I read your POC, I just figure out your solution seems…hum…better 😉

    With your experience, what do you think about my problem ?
    Is there a chance you decide to open your code and/or accept contributions to implement things like files upload or multipart/form-data requests ?
    Thx.
    Wiser.

    1. I am planning on enhancing the current version and offer multipart, uploading, headers,…

      I am not currently intent on opening the source code. I contribute a fair bit of free and open source, and doing that earns me kudos, but I also have a family to feed. I am only a one-man-band and I need to figure out a way to strike a balance and get paid for at least some of the work I do.

      So, at the moment, the plan/experiment with this one is to make it freely available to anyone who wants it with a limitation that you need to download an update every year, and have no access to the source code. Small operators like me are used to and can normally live with such restrictions and can use the software for free. Large companies (I hope) won’t feel quite comfortable using my software, or might want additional, custom features, which they cannot get unless they have a support contract and/or access to the source code, so I might be able to get some support contracts out of it. It probably won’t work, but one can only try, eh.

Leave a Reply

Your email address will not be published. Required fields are marked *