GetURL revisited

Note: If you are using version 0.0.4 or below, it will have stopped working by now because it was time bombed on December 31 of last year. Please update to version 0.0.5 (see link below).
If you are on an M1 Mac, you need to run the host application in Rosetta. I might or might not create an M1 version – all depends on whether I manage to get through my to-do list for paying customers.

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.

It runs till December 31 of this year. One month before that, from December 1 onwards, an updated version with a future time bomb date will become available. Email me and I’ll send you a link.

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("");


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 ( which uses CEP/node as a ‘servant’ to ExtendScript, and does not work on InDesign Server, and 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]

Creative Developers Summit 2020

Two-day virtual developer summit (June 4–5)

The Creative Developers Summit has been the go-to conference for the past half-dozen years for developers creating software for Adobe Creative Cloud applications. This year, sessions will all be online for obvious reasons.

Registration includes all sessions on both days, and it’s only $95 this year, a huge discount from previous years. Because everything is online, we’re going to have speakers prerecord their sessions so you can watch them at your leisure, and then have a fixed online time for each sessions’s Q&A, where the speakers will be there to answer your questions via Zoom.

Sign up here:

We’ll have some great speakers including Davide Barranca, Mike Zahorik, James Lockman, Kris Coppieters and others. Full info will be mailed to you in a few days.

If you would like to be a speaker at summit, and have some interesting topic you’d like to speak about, here’s your chance: send us a brief outline of a presentation you’d like to add to the summit. Send your proposal to [email protected]!

Note that this Summit is complementary to, not competing with, the upcoming “Adobe Creative Cloud Digital Partner Days 2020” which are happening on June 23 and 24:

The Creative Developers Summit is (mostly) about developers talking to developers, and won’t overlap in content with Adobe’s June event.

Hope to “see” you soon!


Mapping out Adobe Creative Cloud apps. Core file paths, app specifiers…

Things like: indesign-15.064 but also photoshop-140.064 and premierepro-14.0. App specifiers as might be needed when debugging with VSCode are not very regular.

Note: appMap.json looks like JSON but it ain’t JSON. It’s JSON++ aka JSON-with-comments, which is not proper JSON. The Sparker app used in CEPSparker and JSXSparker can handle JSON++

The appMap.json file is somewhat readable and contains information that could be valuable for other scripters. Note: when clicking the following link, you might see error messages about invalid JSON. That’s a side-effect of JSON++.

JSXSparker is shaping up – it now handles download-to-running-hello-world-in-2-minutes for Bridge, InCopy, InDesign, Illustrator, Photoshop, Dreamweaver, Premiere Pro.

To support Premiere Pro, JSXSparker now comes with a rudimentary script runner panel, in order to extend the Premiere Pro UI with a means to run scripts.

appMap.json is part of the included starter template configurations.

appMap.json is the ‘roadmap’ to where various Adobe apps keep their stuff.

Amongst other things, it documents what I found out about app specifiers, which are quite ‘irregular’.

appMap.json feeds JSXSparker (and CEPSparker) but it also serves as my ongoing documentation/roadmap into the innards of the Adobe Creative cloud apps