Problems in Ale's relationship with ISIS and Pfeffernusse

Overview

ISIS relies on ALE for generating Image Support Data (ISD) JSON strings for its cube image format. Additionally, Pfeffernusse exists on top of ALE to expose ALE's functionality as a RESTful web service. We must keep the needs of ISIS and Pfeffernusse in mind when designing ALE's interface as they are primary consumers of ALE. As we move to accomplish the work detailed on ISIS3's spice modularization RFC we need to determine the best way to re-design parts of the three libraries to make sure the ALE integration into ISIS goes smoothly.

This document lists out some of the issues between the three tools a possible solution.

Software Requirements and Conflicts

ALE

The Abstraction Library for Ephemerides, ALE's role is to consolidate the complexities of generating Image Support Data (ISDs) from multiple missions given various serialization formats through a collection of instrument-specific drivers and output formatters. There is some syntax sugar in the form of the ale.load function which can be used a single entry point without knowing specific driver names. Ale was originally designed to only use image labels to generate ISD strings but we discovered that some missions will need access to image binary data, not simply labels. For example, HRSC exposure times are acquired from prefix bytes in the image binaries, it's possible other missions will have similar problems in the future.

Pfeffernusse

A spicy cookie from Germany and RESTful web service for generating ISDs from image labels. Essentially a RESTful service on top of ALE for purposes of generating ISDs for images without having to download NAIF Spice kernels for the mission. Similar to ALE, pfeffernusse requests involve sending an image label and getting an ISD JSON string back. Suffers same binary problem as ALE explained above.

ISIS

Our primary SET, must use ALE to generate ISDs and attaches them onto ISIS cubes. ISIS is a C++ library, therefore it needs a C++ interface to ALE in order to generate ISDs. ALE is primarily a collection of drivers, and it's Python interface includes those driver classes. The dynamic nature of ALE drivers makes a C++ interface impractical. Currently, ALE has some syntax sugar in the form of ale.load with a C++ interface. This is a single entry point to ALE's drivers from C++ using only built-in C++ types as parameters. ale.load iterates through drivers until one is successful in a nondeterministic order. This is a non-starter for ISIS as ISIS needs to make sure spiceinit-ed drivers are used before others.

Proposed Solution

Make ALE only accept file paths

ALE will now use file paths instead of only labels. This will give ALE access to the entire image so HRSC and similar missions can be supported. Detached label support will still exist for drivers that do not require image data.

Pros:

• Makes ALE more robust to future missions
• Maintains Label only support for missions that do not require labels Cons:
• String labels will not be supported

Pfeffernusse stays label only and loses some instrument support

Sending large image files over the wire is not practical, therefore Pfeffernusse will still only use labels for ISD generation using ALE's detached label support mentioned above. Missions like HRSC will simply not be supported by Pfeffernusse and you will need to supply your own local kernels and use ALE directly instead. Reducing functionality of Pfeffernusse is less than ideal but ISIS support trumps Pfeffernusse, alternatives involve preprocessing of binary information creating messy process flows.

Pros:

• Label only support is maintained Con:
• Pfeffernusse can only support a subset of instruments.

ALE now has priority ordering of drivers

ALE's ALE.load function will change to have a priority ordering of drivers ensuring that spiceinit-ed cubes are prioritized over others. The new ale.load will simply accept a filename and arbitrary JSON string for kwarg-like support.

Pros:

• ale.load doesn't change it's interface, still uses built-in C++ types for params. Cons:
• ISIS still has no explicit control of which driver is loaded.
• Debugging will still be a challenge.

Alternatives

Make ALE accept a message instead of params

Give ale.load Pfeffernusse's rest interface into a Python function and make it the new single entry point.

Pros:

• clean interface
• C++ friendly Cons:
• doesn't address the binary problem, non-starter for ISIS
• Pfeffernusse's Swagger spec now in ALE

Preprocess Images

Images with binaries can be processed and used as input into ale.load

Pros:

• Pfeffernusse can now support HRSC and similar missions Cons:
• Complicates C++ interface making ISIS potentially more brittle on the C++ side.
• Requires ISIS to call snowflake functions based on missions.
• Complicates workflows on python side as well