Update on R3 Plugins

R3 will provide a plugin mechanism for supporting new features and providing access to external functions and libraries. They are implemented at the OS DLL (dynamic library) level, and a plugin can include REBOL code, native code, and a mix of both.

If you've ever created plugins for other software systems (e.g. for browsers), you will know that they can be difficult to build. For R3, we want to keep plugins clean and simple according to the REBOL rule: simple things should be simple (and more complex things should still be possible.) We want to be able to build a very simple plugin with one page of C code... or even less.

Achieving this goal has been difficult. As we find once again, making a system that is clean and simple takes much more time and effort than one that is large and complicated. The reason is that you write, rewrite, then re-rewrite, until you get it how it really needs to be. You just don't throw the first one out to users and expect them to deal with it.

Those of you who are familiar with the Amiga Computer OS will probably know that it had a few levels of plugin capability. It was an elegant architecture based around a system of dynamic libraries (DLL) and devices (DLD) that I designed for its kernel. (BTW, was the Amiga the first personal computer with true DLLs? Neither MSDOS nor Mac had them at the time, although a few mainframes and minicomputers had the concept. Someone needs to update Wikipedia, no?)

Anyway, it's been a long journey. I've had to trashcan two designs because they did not meet my requirements. They either failed to properly isolate plugins from the kernel, or they required too much intermediate translation at the interface (a high overhead). I've finally settled on a mechanism that's highly efficient, simple to interface (on both native and REBOL sides), and easy to debug.

Of course, those benefits come at a price: it introduces a new evaluation method that can only efficiently be handled by a new datatype: command! (I suppose an alternate name is procedure or proc, but I called them commands because they evaluate differently than functions and they have a shallow context. As always, let me know your thoughts on naming.)

The good news (and my hope, but it has yet to be proven) is that commands will eliminate the need for delect based dialecting. If so, we can yank out delect because it's unneeded (and that would also balance out the extra code for commands - no net increase in the size of REBOL.) I should mention that the effort to implement delect was not wasted, because commands use a related parsing method.

In addition, commands offer a big advantage over delect based dialects: they can use the same embedded auto-doc and help mechanism that we use for all functions. So, unlike delect, where each command word provides a formal argument list only, with command! you can provide a summary string, argument strings, and also return value strings (a new thing.)

So, someday when you type:

>> import %video-plugin.dll
>> help play-video

you'll see:

USAGE:
    PLAY-VIDEO location

DESCRIPTION:
    Opens a window and plays the given video.
    PLAY-VIDEO is a command value.

ARGUMENTS:
    location -- The URL of the video to play. [url!]

So, are you ready to code-up this command?

Yes Pekr, we know it should be called play and then determine if the datatype is video, sound, animation, etc. TBI (to be implemented.)

13 Comments