Design of Dynamic Modules
brazi...@gmail.com
to outline where I think it's going and take feedback if you have any.
Yes, it works on Unix and Windows, and yes, it seems be modeled on
COM, and yes, it doesn't seem unnatural complex, yet. What is the
point? Where is this going?
Netmux and all modules will be linked against mux2.dll (or mux2.so).
This will be a normal import like linking against a system library.
The reason for doing this will become clear in a moment.
At load time, netmux will make an setup call into mux2.dll to give it
a list of component ids that netmux supports internally along with a
GetClassObject function pointer into netmux to create those
components. With this list, mux2.dll will start it's master component
table that maps between component ids, corresponding binary that can
create it, and a function pointer for getting a IClassFactory.
Netmux may see something like the following in the configuration file:
module bin/foo.so
It will pass this file name to mux2.dll which will in turn load the
dynamic module and ask it for its list of supported component ids.
At this point, mux2.dll has enough information to know all the files
used and all the component id use therein. This 'registry' is
maintained within mux2.dll.
To instantiate a component, something calls mux_CreateInstance() with
a component id and an interface id. This function is implemented in
mux2.dll so that it is available to both netmux and other modules.
Before a module can be unloaded, all instances must be released.
mux_CanUnloadNow in every module can be called during @dbck to
determine unload candidates.
Notice that is not necessary for netmux to know all of the component
ids a priori. Two modules can agree on interfaces between themselves.
Netmux still has the ability to @list the loaded modules by asking
mux2.dll.
Eventually, it may be possible to carve parts of netmux code out into
their own module. In this way, a different implementation of that
component could be substituted. And, while there are few tools to
support marshalling, the concept still exists, and it may eventually
be possible to do some cross-process stuff.
There is nothing in this design which ties a module built for one
version of TinyMUX to only work on that version or to even work with
TinyMUX at all.
The real fun begins at defining the components and interfaces. What's
being done now is only plumbing for that. So, it's understandable if
it's hard to see where this is going right now. But, once an interface
is defined (be it for adding a command or function handler or for
getting notifications of certain activity if those interfaces are
defined), it can't change.
The cross-server scenarios are iffy because there are subtle
dependencies in arguments, and having just added UTF-8 to TinyMUX, one
can see how that would have forced two separate but similar interfaces
(one that understands Latin-1 and ANSI sequences, and one that
understands UTF-8 and color code points). The result of this is that
perhaps it would have be easier for both sides to drop one and pick up
the other, but there is nothing in the plumbing that requires this. In
fact, there is nothing that requires another MUSH server to use the
same interfaces to a component that TinyMUX does.
Brazil