Hello all:
I'm developing an app and need to extend its functionality via external modules or plugins. Currently i'm trying to do it using dll/so but don't know if there are better methods to do implement it.
TIA
L
Mailing lists / fpc-pascal / 2010-07
Module or Plugin or similar howto implement?
8 messages · 6 people · –
- Eduardo 2
- Mark Morgan Lloyd 2
- Inoussa OUEDRAOGO 1
- Michael Van Canneyt 1
- Reimar Grabowski 1
- Unknown author 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
I'm developing an app and need to extend its functionality via external modules or plugins. Currently i'm trying to do it using dll/so but don't know if there are better methods to do implement it.
I don't know if there are better methods, but I can say that the dll/so approach works quite well. At least it did for our project. It was written in C++ but I think it will work with pascal as well, if not better due to superior language. :)
hih
R.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Hi Eduardo.
Eduardo wrote 5 lines
Hello all:
I'm developing an app and need to extend its functionality via
externalmodules or plugins. Currently i'm trying to do it using
dll/so butdon't know if there are better methods to do implement it.
In UltraStarDeluxe, a singing game, we use the scripting language lua for plugins.
Michael.
___________________________________________________________ Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
On Mon, 19 Jul 2010 17:13:15 +0200 I don't know if there are better methods, but I can…
Reimar Grabowski wrote 8 lines
On Mon, 19 Jul 2010 17:13:15 +0200
Eduardo wrote:
> I'm developing an app and need to extend its functionality via external
> modules or plugins. Currently i'm trying to do it using dll/so but
> don't know if there are better methods to do implement it.
I don't know if there are better methods, but I can say that the dll/so approach works quite well. At least it did for our project. It was written in C++ but I think it will work with pascal as well, if not better due to superior language. :)
It works, and a dll/so can be dressed up quite nicely as an object. The weakness is the lack of embedded description of the parameters etc. of each entry point.
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
Show quoted text 18 lines
Reimar Grabowski wrote:
> On Mon, 19 Jul 2010 17:13:15 +0200
> Eduardo wrote:
>
>> I'm developing an app and need to extend its functionality via
>> external modules or plugins. Currently i'm trying to do it using
>> dll/so but don't know if there are better methods to do implement
>> it.
>
> I don't know if there are better methods, but I can say that the
> dll/so approach works quite well. At least it did for our project.
> It was written in C++ but I think it will work with pascal as well,
> if not better due to superior language. :)
It works, and a dll/so can be dressed up quite nicely as an object.
The weakness is the lack of embedded description of the parameters
etc. of each entry point.
I was thinking about it, passing data and parameter types to generic modules.
a) I can force to have all modules the same input/output entry point parameters.
b) I can force to register the entry point parameters from data pool (which data the module need from all data the app has)
The first is easier and moves complexity to module developer, the second is easier and more flexible to module developer but more complex to me, perhaps using SOAP like config.
Still thinking in how to do it...
Thanks to all
Eduardo wrote 10 lines
I was thinking about it, passing data and parameter types to generic
modules.
a) I can force to have all modules the same input/output entry
point parameters.
b) I can force to register the entry point parameters from data pool
(which data the module need from all data the app has)
The first is easier and moves complexity to module developer, the
second is easier and more flexible to module developer but more complex
to me, perhaps using SOAP like config.
You need one, guaranteed, entry point per module which returns the version. If you could organise it such that each module is in its own subversion branch (?) but that the interface definitions were stored separately then you might have something usable, /but/ it would rely entirely on strict adherence to coding conventions rather than being enforced by the compiler and runtimes.
I suspect that the "right" way of doing this would be to use CORBA or similar, but I don't know (a) how arduous setting up the IDL description would be and (b) whether that would invariably open sockets etc. even if it were intended to be a local interface.
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
On Tue, 20 Jul 2010 10:21:01 +0000 I was thinking about it, passing data and parameter…
2010/7/21 Eduardo :
Show quoted text 32 lines
On Tue, 20 Jul 2010 10:21:01 +0000
Mark Morgan Lloyd wrote:
> Reimar Grabowski wrote:
> > On Mon, 19 Jul 2010 17:13:15 +0200
> > Eduardo wrote:
> >
> >> I'm developing an app and need to extend its functionality via
> >> external modules or plugins. Currently i'm trying to do it using
> >> dll/so but don't know if there are better methods to do implement
> >> it.
> >
> > I don't know if there are better methods, but I can say that the
> > dll/so approach works quite well. At least it did for our project.
> > It was written in C++ but I think it will work with pascal as well,
> > if not better due to superior language. :)
>
> It works, and a dll/so can be dressed up quite nicely as an object.
> The weakness is the lack of embedded description of the parameters
> etc. of each entry point.
>
I was thinking about it, passing data and parameter types to generic
modules.
a) I can force to have all modules the same input/output entry
point parameters.
b) I can force to register the entry point parameters from data pool
(which data the module need from all data the app has)
The first is easier and moves complexity to module developer, the
second is easier and more flexible to module developer but more complex
to me, perhaps using SOAP like config.
WST* does support "web services" hosted in DLL/SO.
(*) http://wiki.freepascal.org/Web_Service_ToolkitInoussa O.
Inoussa OUEDRAOGO wrote 38 lines
2010/7/21 Eduardo :
> On Tue, 20 Jul 2010 10:21:01 +0000
> Mark Morgan Lloyd wrote:
>
>> Reimar Grabowski wrote:
>>> On Mon, 19 Jul 2010 17:13:15 +0200
>>> Eduardo wrote:
>>>
>>>> I'm developing an app and need to extend its functionality via
>>>> external modules or plugins. Currently i'm trying to do it using
>>>> dll/so but don't know if there are better methods to do implement
>>>> it.
>>>
>>> I don't know if there are better methods, but I can say that the
>>> dll/so approach works quite well. At least it did for our project.
>>> It was written in C++ but I think it will work with pascal as well,
>>> if not better due to superior language. :)
>>
>> It works, and a dll/so can be dressed up quite nicely as an object.
>> The weakness is the lack of embedded description of the parameters
>> etc. of each entry point.
>>
>
> I was thinking about it, passing data and parameter types to generic
> modules.
> a) I can force to have all modules the same input/output entry
> point parameters.
> b) I can force to register the entry point parameters from data pool
> (which data the module need from all data the app has)
>
> The first is easier and moves complexity to module developer, the
> second is easier and more flexible to module developer but more complex
> to me, perhaps using SOAP like config.
WST* does support "web services" hosted in DLL/SO.
(*) http://wiki.freepascal.org/Web_Service_Toolkit
I would also recommend this.
Michael.