TechnicalDesignNotes

The stack of libti*, GFM, TILP and sibling projects (TIEmu, TilEm) projects has been evolving since 1999, thanks to work by Romain Liévin, Julien Blache, Kevin Kofler, Benjamin Moody, and myself.

The set of libraries is obviously not perfect, it needs improvements and possibly a full rewrite into asynchronous mode using a memory-safe implementation language... but that's a lot of work :)

The API and design may seem overly complex at first glance - I know the feeling, that's what I used to think in the beginning too - but... on closer examination, the fact is that if one removes pretty much any of the layers in libti, some more or less significant use case suffers*. In fact, though it may seem exaggerated or counter-intuitive upon a cursory glance to the libraries, we've known for years that 4 libraries weren't enough - see issue #42 . Several examples:

• if one only wants to support the Nspire series, most of the layers described here (especially files and conv) can go. In fact, not only I once performed a one-off experiment to that effect, but there's another implementation of the NavNet protocol which aimed at (excessive, IMO) simplicity by skipping both some layers and significant areas of the NavNet protocol. However, a similar family-specific code base tailored for, say, the 84+ family and the 89T in direct USB mode would have a very similar top-level API, as the protocol and operations provided by both calculator series are similar - so there would be some code duplication anyway if there were multiple libraries. And don't underestimate the fact that even though some aspects leak onto the callers, libti* has provided a unified API for 4 families of TI graphing calculators speaking 3 protocols for over a decade - it's possible if one does it right (enough).
• one can't attempt to meaningfully support the 84+ family and the 89T in direct USB mode without partially supporting the legacy I/O file formats (both for the TI-Z80 and TI-68k series), due to differences in file naming, or simply file formats (e.g. old data files and groups containing data files which are compatible with the 84+ family). That's where the charset conversion layer, and part of the file reading / writing layers, become important.
• one could skip (most) support for the TI-68k family, and shave parts of the calcs and files implementations. However the TI-68k family is one of the most homogeneous ones, and some of the TI-eZ80 series' new file formats and protocols were derived from their TI-68k series counterparts. And although in recent times, Benjamin Moody, especially, brought his TI-Z80 experience, the TI-68k family remains the best supported one in libti*, because the maintainers and main historical contributors are mainly TI-68k users / programmers.
• one can remove a thin layer by supporting only the direct USB cable and giving up on the other USB cable, the TI-Graph Link USB ("SilverLink") for other models... but is it really worth closing a whole family of use cases (paving the way to supporting, with a unified API, older TI-Z80 & TI-68k models using the DBUS protocol, or even the 84+ Z80 family with the legacy I/O port - whose file formats already need to be partially supported, per the above items) just to save a thin, easy cables layer?

The libti* implementation, written in C, uses opaque handles and accessors, structures containing function pointers to provide different implementations of the same operations tailored to one calculator (family) / cable. That is usually considered good programming practice (encapsulation, overriding behaviour, etc.), and would limit the amount of changes to make a full C++ (or other high-level language) implementation of the stack + its main clients.

In 2020, web browser-based calculator communication software is taking off. Such software needn't be limited to TI calculators, of course - the APIs of the layers in libhpcalcs were made to be close to the APIs of the libti* family, for good reasons, and Casio calculators targeted by Thomas "Cakeisalie5" Touhey's libp7******** must be exposing some of the same operations as well. Windows driver annoyances still ruin the fun, but whatever - web browser-based applications have the prospect of being easier to install than libti*/tilp. Nobody can mandate it, but new implementations of the same protocols should be designed correctly from the get go, with feature completeness long-term thinking in mind: adding layers which are superfluous at first, but will prove useful later, saves refactoring time over the long term. Especially since we have nearly a couple decade of clues on how to make a reasonable design.

Still - again, the libti design and implementation needs improvements* :)