Comments on: Clarifying REBOL Lib Interfaces
A104 will be simplifying how libraries and extensions work by merging the REB Lib with the RXI Lib (extension lib).
Here's a diagram to help clarify the design:
- The Host Program is the main program. This is R3/Core, R3/View, or a user's own main program. It contains the Host Lib, functions beginning with OS_ that are passed to R3 Lib.
- The R3 Library is the REBOL kernel. It is called by the host to evaluate scripts. On boot, the Host Lib is passed to RL_Init to provide a way for REBOL to call OS_ functions when it needs to interface with the OS and other services.
- A user can create a REBOL Extension which is a lib that gets loaded as a DLL, or is embedded in the host. The extension is accessed via its RX_ functions. It is passed a pointer to the R3 Library in its RX_Init function. When it needs services from the R3 Library, it calls back via the RL_ macros (which reference a structure of function callbacks.) Example above is a user-defined My_Command function that calls OS_MAKE.
- Embedded extensions can be placed within the Host Program. For example, R3/View includes graphics and other features as embedded extensions. When the R3 Library is called from the host, it can access the RL_ functions directly via the DLL interface (rather than using the RL_ macro interface.)
We intend to use this library interfacing technique across all operating systems, and we hope that objective is achievable.
Will the macros be available in embedded extensions as well, if differently declared? This would allow externalized and internalized extensions to use more of the same source code. If less rewriting is required, it will be easier to change your mind whether to internalize or externalize.|
Yes. Works both ways. Thanks for pointing that out.|
I love it. Looks robust and perfectly conceived.|
Post a Comment:
You can post a comment here. Keep it on-topic.