1. Help with plugin concept
Experts, I need some advice.
I've been working on a plugin for IDE as a test of concept. I've worked up
the first plugin which will open a window in Code Editor to view code
statements for all windows/controls in the order exw would generate them. It
all works very nice as long as in IDE.exw I hard-code the statement "include
ViewCodeBase.plg". Since I will never know the plugin file names the users
write for IDE or even if user is using any, what I wanted to do was place
the plugin files in a subfolder named Plugins. After all the include
statements in IDE.exw I wanted to read the Plugins folder and add an include
statement for each file name found as follows:
--get includes from plugin folder
object files
files=dir(the_current_dir & "//Plugins")
if sequence(files) then
if length(files) then
for i=1 to length(files) do
if not equal("d",files[i][D_ATTRIBUTES]) then
include viewCodeBase.plg <=== gets ex.err
end if
end for
end if
end if
Ha. I forgot Euphoria would not allow the include statement except at the
highest level. So am I out of luck? Any idea how to get around the problem?
~judith
2. Re: Help with plugin concept
Hello Judith,
----------
> From: Judith Evans <camping at txcyber.com>
> To: Eu Forum <EUforum at topica.com>
> Subject: RE: Help with plugin concept
>
>
> The corrected routine is below but it doesn't
> really matter because it will never work.
>
> files=dir(the_current_dir & "//Plugins")
> if sequence(files) then
> if length(files) then
> for i=1 to length(files) do
> if not equal("d",files[i][D_ATTRIBUTES]) then
> --corrected line
> include files[i][D_NAME] <=== gets ex.err
> -----------------------------------
> end if
> end for
> end if
> end if
Try please:
-- code
include file.e
object files
sequence PluginS
integer P_S
PluginS={}
files = dir(current_dir()) -- & "//Plugins") -- just to test, any files
if sequence(files) then
if length(files) then
for i=1 to length(files) do
if not equal("d",files[i][D_ATTRIBUTES]) then
-- include files[i][D_NAME] <=== gets ex.err
PluginS &= "include " & files[i][D_NAME] & "\n" --<-- this is a clue
end if
end for
end if
end if
P_S = open ("plugins.ew", "wb")
puts(P_S, PluginS)
close(P_S)
include plugins.ew
-- end of code
Why not?
Works for me ...
Good Luck!
Regards,
Igor Kachan
kinz at peterlink.ru
3. Re: Help with plugin concept
Hello Derek,
----------
> From: Derek Parnell <ddparnell at bigpond.com>
> Subject: RE: Help with plugin concept
> > -----Original Message-----
> > From: Igor Kachan [mailto:kinz at peterlink.ru]
> > Sent: Friday, 13 February 2004 7:29 PM
> > To: EUforum at topica.com
> > Subject: Re: Help with plugin concept
> >
> >
> [snip]
>
> >
> > Why not?
> > Works for me ...
> This and Aku's suggestion only works
> for interpreted Euphoria.
If you want to compile IDE with *the current set of plugins*
it will work compiled.
> It will not work for a compiled IDE.
Judith doesn't want to compile IDE now,
it seems to be, I think 
And this way is really good and very good,
this way is the Open Source way, MS opens
their sources, I heard ... No? Open Windows!
> And there is no guarentee that it will work for
> future versions as it is an undocumented trick
Well, ask Rob to document this trick as sometimes useful, no
protests. But it is documented in our list archive, let us
read archive, why Rob must document, document and document
these tricks?
> and new versions of Euphoria might not support it.
There is no any reason to abandon the support
of the main Euphoria functions.
Another thing, if Judith wants to add the plugins feature
into her IDE, it may require the detailed specification for
the plugins as to the special include files, as you mentioned
in your e-mail, Derek, and that work is not trivial, yes.
> --
> Derek
Regards,
Igor Kachan
kinz at peterlink.ru
4. Re: Help with plugin concept
Hello Matt,
----------
> From: Matt Lewis <matthewwalkerlewis at yahoo.com>
> Subject: RE: Help with plugin concept
[snipped]
> I typically use Open Watcom 1.0, but
> it's something like a 50MB download.
There is Open Watcom 1.2 on their site now.
Many new things and fixes.
[snipped]
Regards,
Igor Kachan
kinz at peterlink.ru
5. Re: Help with plugin concept
The trick where a Euphoria program modifies an include file
just before including it, does not work with the translator
or the binder, and in the next release it won't work with
the interpreter either.
We may eventually need some new language construct
in this area, but currently you can easily convert
Euphoria code to a .dll, and you can pass Euphoria data
(atoms and sequences) to it, and get Euphoria data returned.
The only problem is, as with all .dlls, you can't easily
share your global variables. You'd have to define a
kind of mini-API, that the .dll (plugin) authors would support.
You can also, of course, run a separate Euphoria program,
via system() etc., and communicate with it via files,
or maybe even shared memory.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Help with plugin concept
Hello Robert,
----------
> From: Robert Craig <rds at RapidEuphoria.com>
> Subject: Re: Help with plugin concept
You wrote:
> The trick where a Euphoria program modifies an include file
> just before including it, does not work with the translator
> or the binder, and in the next release it won't work with
> the interpreter either.
Please, couldn't you explain more detailed what do you
mean when you say it does not work and it won't work.
What a reason ?
It worked and works for me in 2.3 and in 2.4 with ec and bind.
Maybe my tests are wrong or incomplete?
I run interpreted program to create the resulting include
file then run binder or translator with *ready* resulting
include file and *it works*.
[snipped]
Regards,
Igor Kachan
kinz at peterlink.ru
7. Re: Help with plugin concept
Igor Kachan wrote:
> Please, couldn't you explain more detailed what do you
> mean when you say it does not work and it won't work.
> What a reason ?
The example code that you posted was...
P_S = open ("plugins.ew", "wb")
puts(P_S, PluginS)
close(P_S)
include plugins.ew
The above code depends on the open() and puts() taking place
before the include is processed. With the current
interpreter that's what happens. With the current
binder and translator that's not what happens.
Rather, the binder and translator process the include file
(and all other source code) first. Execution of statements
happens later at run-time, when it's too late
for the open/puts to have the desired effect.
In the next release, with the clearer separation between
front-end and back-end, the interpreter will also
process the include (and all other source)
before it executes any code.
It will be simpler this way. I don't think a lot of
people are actually using the above "dynamic" include
technique, although it has been discussed on this list
from time to time.
> I run interpreted program to create the resulting include
> file then run binder or translator with *ready* resulting
> include file and *it works*.
That's fine. You are first running a program that creates
an include file, then *in a separate step* you are using that
include file for translating or binding. However, the users
of your program might not have the translator or binder,
and even if they did, they might not want to run it.
Status:
Currently, I have built:
- a new front-end (written 100% in Euphoria)
- a new back-end for the translator (100% in Euphoria)
- a backend for the interpreter (100% in Euphoria)
I am working on attaching the current C-written back-end
to the new Euphoria-written front-end.
I have extensively tested the new translator
(100% in Euphoria) and it appears to work flawlessly,
as well as being pretty fast.
I now have a Euphoria interpreter written 100% in Euphoria.
It runs all Euphoria programs perfectly (as far as I know),
though it's slower of course. It can even run itself.
I tried running itself, running itself, running itself,
running a small program, and it worked fine, although it
was extremely slow. I'm not sure yet what I'll do with it.
It was extremely easy to implement.
I can translate the Euphoria-written interpreter to make it faster.
I can interpret or translate the new translator. Both can
handle the largest programs, such as Judith's IDE.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Help with plugin concept
On Fri, 13 Feb 2004 18:58:50 -0500, Robert Craig
<rds at RapidEuphoria.com> wrote:
>Igor Kachan wrote:
> > Please, couldn't you explain more detailed what do you
> > mean when you say it does not work and it won't work.
> > What a reason ?
>
>The example code that you posted was...
>
> P_S = open ("plugins.ew", "wb")
> puts(P_S, PluginS)
> close(P_S)
>
> include plugins.ew
>
>The above code depends on the open() and puts() taking place
>before the include is processed. With the current
>interpreter that's what happens. With the current
>binder and translator that's not what happens.
>Rather, the binder and translator process the include file
>(and all other source code) first. Execution of statements
>happens later at run-time, when it's too late
>for the open/puts to have the desired effect.
>
>In the next release, with the clearer separation between
>front-end and back-end, the interpreter will also
>process the include (and all other source)
>before it executes any code.
OK. I have no argument with that.
>It will be simpler this way. I don't think a lot of
>people are actually using the above "dynamic" include
>technique, although it has been discussed on this list
>from time to time.
True.
I cannot however resist suggesting (in pseudo code rather than true or
tested Euphoria, you understand):
in say misc.e:
procedure dynamic_include(sequence filename, sequence contents)
integer changed, fn,
object d
if interpreting or translating then -- see PS
changed=0
d=dir(filename) --##I forget the syntax/results##
if d!=-1 and d[SIZE]=length(contents) then
fn=open(filename,"r")
for i=1 to length(contents) do
if getc(fn)!=contents[i] then
changed=1
exit
end if
end for
close(fn)
if changed=0 then return end if
end if
open(filename,"w")
puts(fn,contents)
close(fn)
puts(1,"dynamic include changed; restarting...")
system(command_line())
abort(0)
end if
end procedure
then:
dynamic_include(filename,contents)
include filename
Does that make sense?
If so, I don't think it is much work and it will (might) put this
issue to bed once and for all.
Regards,
Pete
PS I am undecided whether it would be better for bind/translate to
simply not generate any code whatsoever for the dynamic_include()
call, or issue a fatal error (/warning) if it detects the program
ought to be re-bound/re-translated.
9. Re: Help with plugin concept
Robert Craig wrote:
[snipped, thanks for the explanation]
> In the next release, with the clearer separation
> between front-end and back-end, the interpreter
> will also process the include (and all other source)
> before it executes any code.
Complete pass from single pass to two and more passes ...
> It will be simpler this way. I don't think a lot of
> people are actually using the above "dynamic" include
> technique,
It seems to be ...
> although it has been discussed on this list
> from time to time.
It is useful ... And with two passes it requires some functional
replacement
and reorganization of code ...
> > I run interpreted program to create the resulting include
> > file then run binder or translator with *ready* resulting
> > include file and *it works*.
>
> That's fine. You are first running a program that creates
> an include file, then *in a separate step* you are using that
> include file for translating or binding. However, the users
> of your program might not have the translator or binder,
> and even if they did, they might not want to run it.
Interpreter, translator, binder will give more equal functional results.
Good.
Good reason.
> Status:
> Currently, I have built:
> - a new front-end (written 100% in Euphoria)
> - a new back-end for the translator (100% in Euphoria)
> - a backend for the interpreter (100% in Euphoria)
>
> I am working on attaching the current C-written back-end
> to the new Euphoria-written front-end.
>
> I have extensively tested the new translator
> (100% in Euphoria) and it appears to work flawlessly,
> as well as being pretty fast.
>
> I now have a Euphoria interpreter written 100% in Euphoria.
> It runs all Euphoria programs perfectly (as far as I know),
> though it's slower of course. It can even run itself.
> I tried running itself, running itself, running itself,
> running a small program, and it worked fine, although it
> was extremely slow. I'm not sure yet what I'll do with it.
> It was extremely easy to implement.
>
> I can translate the Euphoria-written interpreter to make it faster.
> I can interpret or translate the new translator. Both can
> handle the largest programs, such as Judith's IDE.
Thanks Rob.
Good Luck.
Regards,
Igor Kachan
kinz at peterlink.ru
10. Re: Help with plugin concept
Rob wrote:
> Igor Kachan wrote:
>> Please, couldn't you explain more detailed what do you
>> mean when you say it does not work and it won't work.
>> What a reason ?
>
> The example code that you posted was...
>
> P_S = open ("plugins.ew", "wb")
> puts(P_S, PluginS)
> close(P_S)
>
> include plugins.ew
>
> The above code depends on the open() and puts() taking place
> before the include is processed. With the current
> interpreter that's what happens. With the current
> binder and translator that's not what happens.
> Rather, the binder and translator process the include file
> (and all other source code) first. Execution of statements
> happens later at run-time, when it's too late
> for the open/puts to have the desired effect.
>
> In the next release, with the clearer separation between
> front-end and back-end, the interpreter will also
> process the include (and all other source)
> before it executes any code.
> It will be simpler this way. I don't think a lot of
> people are actually using the above "dynamic" include
> technique, although it has been discussed on this list
> from time to time.
>
>> I run interpreted program to create the resulting include
>> file then run binder or translator with *ready* resulting
>> include file and *it works*.
>
> That's fine. You are first running a program that creates
> an include file, then *in a separate step* you are using that
> include file for translating or binding. However, the users
> of your program might not have the translator or binder,
> and even if they did, they might not want to run it.
<snip>
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?
Regards,
Juergen
11. Re: Help with plugin concept
Hi Juergen,
----------
> From: Juergen Luethje <j.lue at gmx.de>
> Subject: Re: Help with plugin concept
[snipped]
> <snip>
>
> 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?
Why not? Definitely should with system_exec().
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 ?
Rob, your move
Regards,
Igor Kachan
kinz at peterlink.ru
12. Re: Help with plugin concept
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
13. Re: Help with plugin concept
Pete Lomax wrote:
> I cannot however resist suggesting (in pseudo code rather than true or
> tested Euphoria, you understand):
>
> in say misc.e:
> procedure dynamic_include(sequence filename, sequence contents)
> integer changed, fn,
> object d
> if interpreting or translating then -- see PS
> changed=0
> d=dir(filename) --##I forget the syntax/results##
> if d!=-1 and d[SIZE]=length(contents) then
> fn=open(filename,"r")
> for i=1 to length(contents) do
> if getc(fn)!=contents[i] then
> changed=1
> exit
> end if
> end for
> close(fn)
> if changed=0 then return end if
> end if
> open(filename,"w")
> puts(fn,contents)
> close(fn)
> puts(1,"dynamic include changed; restarting...")
> system(command_line())
> abort(0)
> end if
> end procedure
>
> then:
> dynamic_include(filename,contents)
> include filename
>
> Does that make sense?
> If so, I don't think it is much work and it will (might) put this
> issue to bed once and for all.
>
> Regards,
> Pete
> PS I am undecided whether it would be better for bind/translate to
> simply not generate any code whatsoever for the dynamic_include()
> call, or issue a fatal error (/warning) if it detects the program
> ought to be re-bound/re-translated.
That's an interesting idea.
A bit convoluted though.
I think I'll wait and see if anyone starts
screaming about this issue when the new interpreter
is released.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
14. Re: Help with plugin concept
On 14 Feb 2004, at 13:45, Robert Craig wrote:
>
>
> Pete Lomax wrote:
> > I cannot however resist suggesting (in pseudo code rather than true or
> > tested Euphoria, you understand):
> >
> > in say misc.e:
> > procedure dynamic_include(sequence filename, sequence contents)
> > integer changed, fn,
> > object d
> > if interpreting or translating then -- see PS
> > changed=0
> > d=dir(filename) --##I forget the syntax/results##
> > if d!=-1 and d[SIZE]=length(contents) then
> > fn=open(filename,"r")
> > for i=1 to length(contents) do
> > if getc(fn)!=contents[i] then
> > changed=1
> > exit
> > end if
> > end for
> > close(fn)
> > if changed=0 then return end if
> > end if
> > open(filename,"w")
> > puts(fn,contents)
> > close(fn)
> > puts(1,"dynamic include changed; restarting...")
> > system(command_line())
> > abort(0)
> > end if
> > end procedure
> >
> > then:
> > dynamic_include(filename,contents)
> > include filename
> >
> > Does that make sense?
> > If so, I don't think it is much work and it will (might) put this
> > issue to bed once and for all.
> >
> > Regards,
> > Pete
> > PS I am undecided whether it would be better for bind/translate to
> > simply not generate any code whatsoever for the dynamic_include()
> > call, or issue a fatal error (/warning) if it detects the program
> > ought to be re-bound/re-translated.
>
> That's an interesting idea.
> A bit convoluted though.
> I think I'll wait and see if anyone starts
> screaming about this issue when the new interpreter
> is released.
<scream><scream><scream><scream><scream><scream><scream><scre
am><scream><scream><scream><scream><scream><scream><scream><
scream><scream>
It's things like this, and executing vars and such, that made me drop Eu for a
number of things. You could just as easily encorporate dynamic includes as:
var = fget("filename.e")
function1 = var[50..2000]
function2 = var[2010..3000]
or
execute(var)
But heck, i have been screaming for these things for years, i am now using
PHP to get around Eu deficiencies, especially on nix boxes. You may be
deciding on what the language can do based on the number of people asking
for them, but you won't hear from those who just decide you won't add them
anyhow, and politely quietly move on to other languages. At least i said
something first, repeatedly. People won't use it if they must first ask for
features, wait years, and then see if they get the features. Or get Karl to add
it to his language in a few days.
Kat
15. Re: Help with plugin concept
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
MrTrick
>From: Robert Craig <rds at RapidEuphoria.com>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: Re: Help with plugin concept
>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.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>TOPICA - Start your own email discussion group. FREE!
>
>
16. 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
