Re: Help with plugin concept
Patrick Barnes wrote [quotations rearranged]:
>> From: Robert Craig
>> Date: Sat, 14 Feb 2004 12:50:59 -0500
>>
>> Juergen Luethje wrote:
>>> I believe using the next version of the interpreter, programs still
>>> can take advantage of a dynamic include technique, when the code is
>>> just put into 2 files rather than 1. Then again there are 2 separate
>>> steps:
>>>
>>> ------------------------[ part1.exw ]------------------------
>>> P_S = open ("plugins.ew", "wb")
>>> puts(P_S, PluginS)
>>> close(P_S)
>>> system("exw.exe part2.exw", 2)
>>>
>>> ------------------------[ part2.exw ]------------------------
>>> include plugins.ew
>>> -- Here comes the main program ...
>>>
>>> This should work with the interpreter 2.5, shouldn't it?
>>
>> Yes.
>>
>> Igor Kachan wrote:
>>> Another way is just .bat file (without system_exec() in the first part)
>>> (untested project for 2.5 and better versions
>>>
>>> @ rem -- code of ide.bat
>>> @ rem -- part1.exw prepares all plugins as common include file
>>> @ exw.exe part1.exw
>>> @ rem -- part2.exw executes IDE with plugins
>>> @ exw.exe part2.exw
>>> @ rem -- end of code
>>>
>>> This is EU, isn't it ?
>>
>> Yes, that will work too.
>
>
> The only problem with this method of plugins....
>
> The resulting IDE is still monolithic... let me explain:
>
> If you load/install a 3rd party plugin for your ide, that is missing an
> external include, or has bugs...
>
> Then prg2.exw, or whatever you call it, will crash. And the user will not
> necissarily know what has happened, and unless the plugin installer-loader
> is separate from the main ide, there is not a user-level way to unload it.
>
> I know that the trickery that you have described will work, as long as all
> the plugins are perfectly working. However, for a more robust ide, the idea
> of dll's and an API is much better, as it allows for some kind of "This
> plugin could not load" message, and for the IDE to continue functioning.
>
> Unless of course, Rob allowed an "include(sequence file)" function, that
> returned either 0 for success, or an error code showing how the include
> failed... It's ok Rob, maybe for Eu2.6
>
> ;oP
Derek already wrote something about different types of plugins.
When a plugin is a DLL, a serious bug also can cause a program crash.
As I understand it, "API" is a general expression, i.e. this term does
not only refer to DLLs. I think any program, that wants to utilize 3rd
party plugins, should provide an API, regardlesss what way the plugins
are technically implemented.
For example Judith can say, that any plugin should have a function
called plugin_id() that returns say Judith's birthday times PI or
whatever. If the function returns a different value, the main program
can raise a "File 'xyz' is not a proper plugin." message.
If the main program calls a routine in the plugin that does not exist,
the program will crash, regardless wether the plugin is an interpreted
EXW file, or a DLL. In this situation a crash can be prevented by using
the routine_id() technique, and this will work with interpreted EXW
files as well as with DLLs.
Please notice that these are just some general considerations. I don't
want to recommend anything concerning plugins, because I've little
experience in this field.
Regards,
Juergen
|
Not Categorized, Please Help
|
|
