Component technologies
From ESEwiki
Based on extract_internals.
Design an inter-process protocol: object migration (copy vs. distant reference), network protocol, remote feature call, maybe a central data repository?
Design a tool framework to build "managers" that can manage the independant components (allowing to start/stop them, restart them and so on), maybe also serving as data repository
Design a tool for plugin creation
This page currently contains only a few notes. Everything has yet to be designed.
Contents |
Introduction: program extensions
There are two sorts of extensions: parallel programming (using multi-process[1]) and object integration (some kind of plugin management).
Multi-process with object exchange
The "closed world" paradigm is very useful. It is the very first basis of SmartEiffel, which makes it so powerful. Removing this constraint would not only remove many possibilities of optimization, but imply a major shift. It is not desirable.
But on the other hand, we would like Eiffel programs to communicate. It is not because one program does not create objects, that it cannot receive them. True? Well, not exactly. It depends on what we think a "program" is.
To me, a program is not a process. It is a collaborative set of process who work together to provide some feature. In this light, we can keep the "closed world" paradigm if SmartEiffel is extended to be able to provide, not one, but many executables.
If this is achieved, having processes exchanging objects is just a matter of them being part of the same program. And if you think about it, that's just obvious: programs cannot communicate (because they have nothing to do one with another). But processes should be able to, if they are but parts of the same program.
Note that I want it to be really powerful. I want at least the following features:
- Many executables on many platforms. That is quite simple since SmartEiffel compiles to ANSI C, but there are subtleties such as endian-ness.
- One program means one command line.
- One program also means one ACE file[2].
Object integration
It would be very useful if a program could integrate third-party libraries to extend the program. The best way is to enable the creation of plugins, because plugins depend on the program, but not the opposite[3]. In other words, the program is still a closed world; but plugins can "be invited".
How do you make a plugin? Technically, it is a "shared library" (DLL on Windows, or .so on UNIX). This is really low-level because you can pass only low-level data through the barrier: integers, floats, and pointers. That's quite enough though, because everything else can be built in Eiffel.
The question is, how do objects cross the plugin barrier? Even, do they? The answer is, it depends on who created the object.
- If the program created the object, then the plugin can use it quite directly. The barrier will be passed using a very small C glue that passes a pointer to the plugin. That pointer being a reference to an INTERNALS object.
- If the plugin created the object, then the program won't use it directly---the object "stays" in the plugin. The program will use a proxy to the object. It means that the program must be aware that a plugin can be, well, plugged. That's just obvious[4].
Note that the plugin must have been compiled with some knowledge of the program. The simplest way is to build a .id file for SmartEiffel to use when compiling the plugin.
A tool must be written that easily writes the proxy. That's simple enough: it takes some abstract class and derives one concrete class that talks to plugins via a shared library interface.
The toolchain would then be:
- write the main program, with abstractions for the plugins;
- use a tool that writes the code of the proxies using the abstractions;
- compile the program; also generate the .id file to distribute to the plugin writers;
- third-parties can write plugins and compile them using the provided .id file.
Earlier works
- SEDL could be used as preliminary work for plugins
- See the blackboard
Notes
- ↑ I don't believe in SCOOP. It is too complex. The future lies in process communication, not in thread soup.
- ↑ or whatever equivalent "make file" as long as it is unique
- ↑ Compare that to libraries: a program depends on a library. That's why libraries cannot be compiled separately.
- ↑ Note that the program created the proxy; so it could be passed back to the plugin itself. It could also be given to another plugin. This has to be carefully designed.
