Being here in San Rafael, it seemed like a good opportunity to put pen to paper on the internals of the JavaScript API introduced in AutoCAD 2014. It's a topic I've been meaning to get to for some time, and sitting in the cube next to Albert Szilvasy helps me get information straight from the horse's mouth, as it were (no offence, Albert ;-).
For those of you who don't know Albert, he's someone who has had an incredible impact on the AutoCAD product, over the years, particularly from a platform perspective. Albert was the person to architect and introduce AutoCAD's .NET API, and is now doing the same for JavaScript.
Albert and I go back a looong way. I first met Albert in 1996 (I think), when I was in the "Developer Consulting Group" (a former incarnation of "Developer Technical Services" – or DevTech – the technical arm of the ADN team). I was presenting at the first Eastern European developer conference we'd held, in Brno in the Czech Republic. I was presenting on AutoCAD's APIs with a particular focus on ARX (before it was known as ObjectARX), and there was one extremely sharp guy – Albert, of course – in the audience asking very pointed questions. He was still at university in Hungary, at the time, and was sharing his experience of implementing a robotics-related project inside AutoCAD using ARX. We shared more than a few drinks after the event, and I was delighted when Albert eventually ended up joining the ADN team in San Rafael. Albert later transitioned into the AutoCAD Engineering team, and the rest is history (and trust me when I say that the AutoCAD product is far better for it).
But I digress: let's get back to talking about JavaScript inside AutoCAD…
To get JavaScript working inside AutoCAD, we've integrated the open source Chromium component into the product. This gives us the all-important V8 environment for executing JavaScript as well as a WebKit-based browser for rendering HTML content. You may have heard that Google is forking WebKit to continue development on their Blink rendering engine. This shouldn't change anything for us, moving forwards: we may well choose to – at some point – move to a newer version of Chromium, and it'll happen to be based on Blink.
One of the main reasons for going with Chromium rather than WebKit is that its JavaScript engine – V8 – is extensible. This allows us to add our AutoCAD-specific JavaScript APIs into the engine, making them available to code being executed by it.
Chromium is hosted in a separate process to AutoCAD: AcWebBrowser.exe. This process communicates back to AutoCAD via IPC – which should be just fine even for interactive processes such as jigs (where we have to pass a point from AutoCAD to our JavaScript code for each mouse movement). That's not to say there isn't some marshalling overhead associated with this communication – there is – but the benefits of having a separate process executing the code – particular around fault isolation – led to us making this trade-off.
The browser component loads what's known as the JavaScript Shaping Layer when it starts. This is a generic API implementation layer that communicates with the host environment – in our case AutoCAD – via a small number of entry/exit points: exec(), execAsync() and registerCallback(). Any arguments that are needed for these functions – such as the options provided to the getInteger() method – will be encoded in JSON to be communicated via the IPC mechanism.
The beauty of limiting the implementation to make use of these few functions is that it becomes much more easy to translate across to other platforms – the layer itself is portable and having fewer connection points will reduce the amount of native development needed on each platform. At least that's our expectation. That doesn't mean, of course, that no work is needed to actually fill out the implementation behind these entry/exit points – that is work that clearly needs to happen – but we're keeping the number of core connection points down to a small number and designing them to be as streamlined as possible, which should also help minimise the impact felt by the IPC marshalling overhead.
This marshalling happens between a native proxy inside AcWebBrowser.exe process and a native stub inside AutoCAD. With – as mentioned earlier – the marshalling of data happening via JSON.
Something that's interesting for developers – and I know Philippe Leefsma has been looking into this and will no doubt post something soon on the AutoCAD DevBlog – is the ability to use acjsDefun() to register your own stub functions that can be recipients of the calls coming in via IPC. You'll presumably need to essentially extend the Shaping Layer with your complementary JavaScript code that makes use of exec(), execAsync() and/or registerCallback() calls, but you won't need to implement native code to extend the proxy implementation inside the browser process.
One thing that's worth mentioning about the JavaScript Shaping Layer we've created: it's being written in TypeScript, which gives us the ability to work in a more object-oriented fashion than JavaScript inherently provides, before compiling it to JavaScript and publishing the output. This is certainly something that people using the JavaScript API will want to look at doing themselves, depending on the complexity of the application they're working on.
I think that's probably enough information for today (I wonder if anyone actually made it down this far – please post a comment if you did! :-). I'll follow up on more information about this new API capability as I discover (or uncover) it.
Leave a Reply to Ignacio S Cancel reply