FerretX: Difference between revisions
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
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<ref>In the case of interpreted languages, this often means recompiling the language interpreter itself, which can create a technical debt situation since the standard package updates can no longer be used</ref>. 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 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<ref>In the case of interpreted languages, this often means recompiling the language interpreter itself, which can create a technical debt situation since the standard package updates can no longer be used</ref>. 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 | The inspiration for FerretX is a Microsoft technology which I think was called "ActiveX DLLs", but the [[wikipedia:ActiveX|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. | ||
The | The immediate needs for this: | ||
* I want 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 [[htyp:PHP/GUI|graphical interfaces]] and "ncurses" (a full-screen text-mode library) | |||
* I want to be able to talk via ssh to database engines that are closed to direct outside access. | |||
** A simple server-side FerretX app will expose an API for local database interaction. | |||
*** Would this be a security-hole? Kind of not really; you still need ssh access and the right to run the program in question. ...and since it's only intended for administrative sorts of uses, it could be disabled most of the time, and all accesses could be logged and reported, if need be. | |||
==Concept== | ==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: | 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: |
Revision as of 14:38, 4 September 2023
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[1]. 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 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.
The immediate needs for this:
- I want 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)
- I want to be able to talk via ssh to database engines that are closed to direct outside access.
- A simple server-side FerretX app will expose an API for local database interaction.
- Would this be a security-hole? Kind of not really; you still need ssh access and the right to run the program in question. ...and since it's only intended for administrative sorts of uses, it could be disabled most of the time, and all accesses could be logged and reported, if need be.
- A simple server-side FerretX app will expose an API for local database interaction.
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.
Footnote
- ↑ In the case of interpreted languages, this often means recompiling the language interpreter itself, which can create a technical debt situation since the standard package updates can no longer be used