Comments on: Plugins vs Plugin (decided)
We have a small problem:
In R3, plugin components are called "plugins". These are function libraries that allow you to extend REBOL.
There is also the REBOL web browser plugin. This allows you to run REBOL (2) in the browser window.
If you Google "REBOL plugin" you will get links related to the browser plugin. You will see no links to the plugin component docs.
Perhaps before we release plugins, we need to decide if we should change them to some other name. In R2, the similar concept is called a component.
So, keep it as plugin or change it?
Now is the time to decide. After this point, we cannot go back.
The name extensions is a reasonable alternative as mentioned by many developers. It is used with several other languages and it has a short form "ext" that can be used when needed.
Changes will be made to update all files, APIs, prefixes, suffixes, documentation and links.
Thank you for the quick feedback... so we can get it released.
I think the term "extension" could be used.
component seems internal, where as extension implies that its something external hooking up inside.
a "REBOL extension" seems pretty obvious in semantic... whereas a "REBOL component" isn't.
plugin is used extensively for many things, but because the browser is a prevalent part of modern computing, it has probably diluted the meaning of "plugin" in general.
the word plugin seems to be attached to "flash plugin" in such a way that the word almost seems to imply a plugin for a browser nowadays.
we can also use the term "Library" but that's even less clear than component, IMHO.|
I would not mind the name change. If you look for e.g. at Mozilla, they distinguish too - plug-ins are for browser plugins, and things which extend Firefox itself, are called extensions, or add-ons. It is just that extension is a little bit long name. OTOH extension is absolutly clear term.|
I believe that "extensions" is used in both Python and Ruby. It is very clear and appears to be commonly used.
Runtime Revolution uses the term "externals" which originates from Hypercard.
Either would be better than plugins for me.
I vote for "extension"|
Overall, I prefer "plugin", but "extension" would probably do. I agree with Maxim that "library" wouldn't be clear - hard to distinguish from ordinary DLLs and such. The word "wrapper" seems to apply in the case of wrapping an external library, but the term is generic and doesn't cover self-contained plugins that aren't wrapping anything.
Mozilla "plugins" are more like the extending-REBOL plugins you describe, at least architecturally. Their "extensions" are more like our modules - but without the common integration interface, like R3 has with plugins and modules. Mozilla doesn't really have a term for the browser itself being a plugin of another app, which is the closest corresponding idea to a REBOL browser plugin.
If the name must be changed, I like the "extension". But personally I don't care how you name it if it will works.|
There is also "addon" or "addition". The term "addon" gets a lot of use for this kind of thing, and is short. Still prefer "plugin" though.|
The question is - do we really mind, if search for "REBOL plugin" give us mixed browser plugin, and R3 plugins? I mean - R3 itself is going to be a plugin for browser, and R3 can be extended by plugins, too. So - is the risk of user confusion really so high, that we have to change it? Contrary to "extension" term, e.g. Photoshop has "plugins" too. I think plugin, extension, addon - all are OK for me, no strict preference on my side ...|
I think that "extension" is the commonly used term, and would be understood by most users. As long as it's not "DLL";)|
RonH - according to initial Docs, it seems, that we are going to get .dll extension. I don't like it too - it implies 1) Windows 2) the acronym is - dynamic loadable library. But plugins are meant to be more than libraries, aren't they?
Maybe it uses DLL extension, because plugin code can be directly compiled into one? But - then we are using simplicity for something 10times complicated than R2 DLL wrapper is, anyway. I would probably prefer builder scripts and .plg or .ext extension, simply as we had .rip in the past.
What if I want my plugin to contain some additional resources, e.g. image, whatever?
Still considering these inputs. A77 delayed until we decide.
Pekr, the subsystem is called "plugin" right now not "DLL". Sure, it uses the OS DLL mechanism because it needs to dynamically load native code and data. You can use other file suffixes, but they probably will not work on Win. (But, maybe, not sure.)
Also, you miss the main goal of plugins: to allow you to define your own native functions. Of course, since it is built on R3 modules, you can also include non-native code, data, images, whatever you want, and control how all of that is exported to your apps.
Also, you will find this mechanism to be very easy to use, easier than R2 in fact. And, do not forget... look at any other plugin system, and you'll see what kind of garbage we have eliminated from this design.
'Extension is a nice, well-known word. 'Adjunct is a nice word, but nobody will know what it means. 'Expansion might work, as in the context of an expansion pack for games and such.|
From a users POV optional enhancements or extensions of a language
- often cryptically called "dialect, plugin, addin, addon, snapin, snapon, modules" etc. and differently written (plug-in, add-on etc) -
are just additional functions or "features" provided on request.
The mentioned "distinctions" seem superficial, i.e. neither precisely defineable nor delimitable from each others. I think they are synonyms.
Anyway. It's enough and advisable to use just one term for them: Addon, extension, option, or something like that...
If wanted for Google, elsewhere used synonyms can be added in brackets. ;-)
Carl, you can use other extensions for DLLs on Windows - that's what .ocx and .exe files are. LoadLibrary is not picky about file extensions - not sure about other platforms.
Using a different file extension would be helpful for wrapper plugins, to distinguish from an ordinary DLL. It could help with the codec loader too. No need to limit yourself to 3 characters, but start with .r though, for the branding.
However, if you can't use another file extension on other platforms, there may be no point to doing it on Windows.
The file extension .rext isn't being used...|
A lexicographic remark - If the mecanism also could wrap dlls, then the word 'assembly' or 'assemblies' are also often used. This naming convention is well known for dot Net; an ECMA standard also grasped under Linux.
Apart from the usage of the word in the IT field, for its semantics, 'to assemble' "to put together, to connect", "réunir, monter ensemble", does suggest an integration of parts that should work together, here said of all sorts of binaries. Such common language semantics is valid both in English, and French. Also, specificaly for technology, in italian 'asemblare', in spanish 'ensamblar', and said of machines, in german 'zusammenbauen'.
Ok so now all we have to do is writing an "extension" generator and compiler.
Who starts ?
A77 released. Try out extensions. Still simple, but some of you will find them useful (and fun, maybe.)
Example code posted in R3 CHAT #5045 group.
Type: get #5078 to download it, then OD to open the dir to the zip. MSVC project file is way old... 6.0. But, any compiler should work. Perhaps a few warnings we'll need to clean up.
starting work on a DevC++ version of extension project.
I almost can't believe I'm actually doing this... been waiting for sooo long... :-)
So, do I get a prize for coining the term extensions? ;-)
Post a Comment:
You can post a comment here. Keep it on-topic.