Future maintenance of AA functionality

[Carifio24]

In order to do many of its astronomical calculations, WWT includes functionality from the AA+ library, which is a C++ implementation of a variety of astronomical algorithms. As AA+ is written in C++ and the web engine is in JavaScript, this functionality is included via a C# translation of the library that was then transpiled into JavaScript.

While it's very cool that this was done, the issues fixed by #347 make clear that this not a super maintainable approach - it puts the onus on us to do the necessary maintenance (bugfixes, at least) on what is functionally an upstream dependency. @patudom and @johnarban and I had a brief discussion about this the other day, but I think we should investigate the feasibility of moving off of the WWT JS implementation.

I can see two possible options for doing that:

1. There is an AA.js package that essentially does this.
2. We could create a WASM build of the AA+ code directly (using emscripten) and then load and call into the WASM build of the library

Worth mentioning:
There is a Swift implementation of AA (don't see any way for us to use this), and a C# implementation (we've moved on from our C# transpilation, so also not super useful).

Provided that we think it's well-enough maintained, I would be more inclined towards option 1. We don't use WASM anywhere else in the engine, so a JavaScript dependency would slot more simply into our existing codebase. Plus, if we ever find that AA.js isn't well-enough maintained, creating our own WASM build is always an option.

Would love to hear any thoughts from @patudom @johnarban @pkgw @astrodavid10

[pkgw]

Yeah, I agree that option 1 sounds like the sensible way to go.

Be aware, though, that at a minimum there some AA types that were renamed during the conversion, and I would worry that there might be some custom hacks to the code slipped in there. Ideally we'd have some nice thorough testing to make sure that we're preserving behavior across any implementation swapout.

Also, if I remember correctly, the current implementation does use the janky, bespoke OO/inheritance scheme from ScriptSharp — it's possible that there are elements of the engine codebase that rely on that, which would require some kind of wrapping or updating to work with AA.js.

Then also, from an API-stability standpoint, ideally the engine JS library should keep on exporting all of the existing AA names with all of the same calling conventions, so as not to break any downstream consumers that use the existing APIs. The AA stuff is clearly thought of as in internal implementation detail of the WWT engine, but it was exposed publicly and there might be pieces of code that rely on the details of how it currently works.

[Carifio24]

Those are all great points @pkgw. And you're right, the current implementation does use the ScriptSharp registerType scheme, so as you mentioned we'll need to add some kind of wrapping to preserve that, and make sure that what does get exported has the same API as what currently exists.

The first point seems the most potentially problematic to me. I think you're right that we'll need to add some thorough testing - probably some unit testing on the AA classes that WWT exports, probably together with some kind of higher-level tests of relevant WWT use cases.