Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library

Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-08-15 17:34:46

On August 15, 2014 2:42:38 PM EDT, Niall Douglas <s_sourceforge_at_[hidden]> wrote:
>On 15 Aug 2014 at 19:22, Klaim - Joël Lamotte wrote:
>
>> > It definitely has the wrong name because it doesn't implement
>> > plugins, it basically is a wrapper for the POSIX and Windows
>dynamic
>> > shared library functions. Boost.SharedLibrary is a far better name.
>> >
>> >
>> In my experience the "plugin" word is used as soon as a shared
>library
>> could be loaded at an indeterminable time during execution (and be
>unloaded
>> too).
>> This is different from just "shared library" which is both a plugin
>> implementation and a library linkage, including having the library
>> automatically loaded
>> at startup.
>> To me plugin is far more precise than "shared library".
>> You don't need such a library to make a shared library. You would
>need such
>> a library to make a plugin (or extension, or module) library.
>
>A plugin/extension implies a well defined exported symbols and event
>processing ABI. Something adhering to Microsoft COM is a good
>example.

What that term implies is based upon one's experience. "Plugin", to me is any dynamically loaded component. The ABI you mention depends entirely upon the ubiquity of the plugin. If it must be usable by many applications and customers, it must have a documented, even standardized, API. Just as easily, however, one can create plugins based solely upon dlopen() (or LoadLibrary()) and friends of the plugins are used only for one application.

>Antony's library is far more low level, it really does just thinly
>wrap the two popular shared library APIs into a portable API. It says
>nothing about what the ABI should be other than C compatible, any
>form of inspection other than C format symbols, or anything about any
>event model. I wouldn't mind calling his library a plugin solution
>for C, but it isn't up to task for C++.
>
>> Even CMake call them "module", not "shared" libraries. Even if
>implemented
>> in unix-like systems as just "shared" libraries,
>> it's still a special case of shared library, not the general case.
>
>Unfortunately Boost.Module might get confused with forthcoming C++
>Modules. Otherwise I wouldn't object to that name.

I use "dynamic library" as the generic name in my library.

___
Rob

(Sent from my portable computation engine)