Comments on: 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 Comments:
Brian Hawley
22-May-2009 21:52:35 |
It is always good to hear that a design that is not up to snuff has been replaced by a new design. And now is the time to do this, before the design flaws get codified. This plugin model sounds like a good approach, a good balance.
introduces a new evaluation method that can only efficiently be handled by a new datatype
I look forward to hearing more about this in depth. | jocko
23-May-2009 2:20:08 |
Usually, a plugin mechanism is based on standardized interfaces. Will you provide a plugin system for extensions (players, ports ...) written on purpose, and keep the R2 way of accessing pre-existant dll's (like Windows system dll's), or will it be done through the plugin? | Brian Hawley
23-May-2009 10:36:01 |
In theory, Jocko, you should be able to implement a generic DLL wrapper dialect with a plugin, though it would likely require separate wrapper plugins for DLLs with different calling conventions: C for *nix, C++ and .NET for Windows, Objective-C for OS-X, Java. R2 only supported a subset of C semantics, and not any of the other languages.
We will see if that will be necessary or possible once we hear more about the plugin mechanism in depth. | -pekr-
23-May-2009 10:41:17 |
Looks good so far. I wonder what will be the consequence for DLL interfacing model? We have some nice enhancement proposals in the wiki-doc. Should DLL interfacing (the R2 way) be done as a first plugin?
Can plugins define datatypes? (struct! routine!) ... and also - can some plugins be embedded in REBOL (but still being a plugin?). What I have in mind is, that perhaps the most usefull ones could be part of rebol.exe distribution (or some special distribution), not a separate file ... | Robert
23-May-2009 14:14:11 |
Great to hear this. My C compiler is ready to go.
IMO the "hard" part will be the interface to different backend languages like Brain mentioned. But, most can at least provide a C compatible function signature and calling convention.
And, I hope the interface is two-way. Rebol can use the new commands and the DLL can access Rebol internals (values, windows, GOB, ...) via a simple interface. | Normand
25-May-2009 10:58:24 |
Of course, a good candidate exemple to proof the new plugin scheme would be RT providing a full featured driver of SQlite through it, as the designer knows best to interface the code to the (so we hear) borrowed B-tree of SQlite integrated into R3. Official language support of SQlite would give credibility to Rebol for business applications. | Maxim Olivier-Adlhoch
27-May-2009 18:21:53 |
having datatype creation is one of the primary needs I have for the plugin.
I can't wait to be able to do:
subordinate: make plug! 69
observer: make plug! none
observer: subordinate ; link to subordinate.
observer: subordinate ; again
probe observer
== [69 69]
observer/process: [add data/1 data/2]
probe observer
== 138
subordinate: 10
probe observer
== 20
| Anton Rolls
28-May-2009 13:09 |
Just quickly I think 'procedure' or 'proc' is better than 'command', because I use 'command' as description of functions in dialects I write, eg. a text editor I wrote had 'commands' (like 'move-left' 'page-up' 'cut' etc.) | Cyphre
28-May-2009 16:30:31 |
You can make calls to a plugin...what about using call! datatype instead of command!...just a quick idea.
| RobertS
28-May-2009 18:35:37 |
Developers conversant with Patterns already have Command as the name of a Pattern. If used in making a call to a DLL, then call! seems a natural name choice. | -pekr-
29-May-2009 0:17:26 |
I would not mind even calling it a routine!, as it was with R2, although with R2, it was more direct wrapper to particular DLL routine ... | meijeru
29-May-2009 14:01:47 |
routine! has my vote too; it suggests quite well a shallower type of procedure (see Carl's remark) and it has R2 lineage | Maxim Olivier-Adlhoch
10-Jun-2009 16:35:40 |
command!, IMHO, really isn't a good name, as others above have noted.
I'd prefer routine! since call is ambiguous and is easily mistaken as having a relationship to the R2 call native (which I hope will be part of R3 core distro as well).
|
Post a Comment:
You can post a comment here. Keep it on-topic.
|
