Hi Justin,
I’m not sure if you can extend the DOM in After Effects…?
First, when I say “plug-in”, below, it includes InDesign native features, as well as 3rd party plug-ins. InDesign itself is nothing but a collection of plug-ins.
There are no cases in InDesign where an ExtendScript function isn’t exposed in the C++ API. (Or there shouldn’t be–it’s always possible.) Scripting is built into every plug-in function that can touch the document–it’s not added on, after the fact, as it is in most other apps. On the other hand, there are some C++ functions that aren’t supported in scripting, so we add support for those, as well as adding entirely new functions.
As far as communication goes–it’s just InDesign scripting. The objects/methods/functions added by our plug-ins are merged into the InDesign DOM at startup as first-class citizens. They even appear in UXP. The other benefit is that objects/properties added to a document by the plug-in will be supported in .idml/.idms (InDesign’s interchange formats). (I’ll admit that I’m proud to have been involved in the development of InDesign scripting.)
re: Install Process–yes, I’m pretty sure these have to be custom installers. I have to check with the installer guys to be sure, but I think we’re still using the approach we took with CEP extensions–the CEP parts go the OS-mandated places; the C++ plug-ins go to the InDesign Plug-Ins folder.
re: CLI access–I don’t know that we’ve done this with UXP plug-ins, to date. For CEP, we used a mix of approaches. We’ve also used InDesign’s app.doScript() to run AppleScripts and VBScripts, as needed.
For better or worse, a lot of our work requires XML, so those parts will stay in ExtendScript as long as possible–E4X is superior to anything “modern” JavaScript has to offer (that I know of). Telling large corporations to “just use JSON” doesn’t work very well.
Also, we work with .idml/.idms extensively, and those are XML formats. In some cases, we serialize these into JSON, depending on what we need to do.
Thanks,
Ole