Data Sets #

Imagine for a moment, a plugin implementation, where the plugin can offer a subset of a well defined set of functions.

The way Windows DLLs used to work, by having every function have its address in a well known position in an array of addresses.

The way shared objects on Unix often work, where each function is looked up by name to find its address.

The way some other plugin systems do it, with an array of < index, address > duples, avoiding the need of huge and sparse arrays.

Or… the way a Unix kernel does it, through a dispatch function, which takes a well known function number, and a varying set of arguments. This dispatch function looks at the function number to decide what arguments to expect, and what to do with them.

Imagine for a moment, a very simple structure to represent an encapsulation of, well, anything pluginable

dispatch

is the address to the dispatch function that implements all functionality of the encapsulation, apart from destruction.

This dispatch function has always the following signature:

uint32_t dispatchfn(T *o, int num, ...);

where o is a pointer to the encapsulation, num is a dispatch number, and ... are arguments that should be passed to the implementation of that dispatch number.

This dispatch function should never be called directly. Instead, wrapper functions should be used.

destroy

is the address to the destructor function.

data

is the address of plugin internal data. Essentially, only dispatch and any of its sub-functions are expected to know the contents of that internal data.

When this encapsulation is created, it’s populated with known dispatch and destroy functions, while data is left NULL. The data is goverened entirely by the plugin implementation.

This is the Data Set, which has a foundational Le’Sec Core element.