FerretX

Intro

The key idea here is to make it easier for any language to make use of libraries written in any other language, and for compiled languages to make use of compiled libraries without having to recompile and link them. It also is especially useful in integrated development environments with code-aware autocompletion (CAA) features, in that it provides the necessary information for CAA when using a library whose source-code is not included in the project.

The immediate need for this comes from my wish to use certain libraries in PHP that are well-supported for other languages but either not available in PHP at all or else poorly supported -- notably graphical interfaces and "ncurses" (a full-screen text-mode library).

The inspiration for FerretX is a Microsoft technology which I think was called "ActiveX DLLs", but the Wikipedia entry on ActiveX only mentions it in passing and certainly doesn't do credit to how useful it was in environments like Visual Basic 6 and Access 97.

Concept

The idea is to use JSON (or any open protocol that can encode arbitrary data-structures as text in a binary-safe way) to communicate:

• class/object interfaces
• object data

We will need to start with:

• a command to retrieve all interfaces
• a command to retrieve the details of a particular interface
• a standard structure for defining method APIs (static/dynamic, paramter/type list, return type)
• a way to call any given method within an interface (directly for static methods, or with an object as an implicit argument for dynamic methods)

Details

Sequence of Events

• The client checks that the server is loaded. (The server can either be always-running or load-on-request, individual threads or common thread.) For the first implementation, the server will be a standalone process that the client loads when needed.
• The client requests the server's status. If the server reports an error, or does not respond properly, then the client passes that information back to the user in some appropriate way.

Data Format

All communication takes place by passing structured keyed arrays back and forth. For the first implementation, I'll be using JSON as the encoding format, but any other serialization format (such as YAML or XML) should work, as long as both client and server can speak it.

What is particular to this usage is the content of the structure being conveyed.

The following is tentative and experimental.

Each communication between client and server is called a message. The two main message types are:

• question: client asks server to do something or return some information
• answer: server responds to client's question

TBD: When a process takes awhile, we'll probably want the server to be able to update an answer without being asked.

The array-structure for each of these message-types:

• question = {question name} (like a command/function name)
  • argument_name = {argument value}
  • argument_name = {argument value}
  • ...
• answer = {status code}
  • data...

Most messages will be in an object-context; only the top-level API-query dialogue takes place without specifying an object.

API questions:

• "identify": asks the server to confirm its identity and return version information (the server will also do this automatically when first started)
  • "name" = short name of program/library
  • "summary" = one-line description
  • "version" = version string
• "classes": asks the server for a list of classes/interfaces
  • Each class may then be queried for details.
  • TODO: We might want to include some overall details about each class (attributes, inheritance?)

WRITING IN PROGRESS

Notes

I need to understand Spritely Goblins and OCapN, which sound like one or the other of them might be basically the same idea. It certainly sounds like it ends up supporting similar capabilities.

• Spritely Institute
  • 2023-01-30 Spritely Goblins v0.10, for Guile and Racket!
  • Spritely's Goblins and How They're Gonna Steal the Future
• OCapN network suite