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

Subject: Re: [boost] Checking interest in DynamicLoad/DLL/DSO/Plugin library
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-15 15:17:28

On 15 Aug 2014 at 20:56, Klaim - Joël Lamotte wrote:

> > A plugin/extension implies a well defined exported symbols and event
> > processing ABI. Something adhering to Microsoft COM is a good
> > example.
> >
> > 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++.
> >
> >
> I see.
> To me it's a good starting point and I fear that a more C++ than C library
> ends-up like boost.extension. But if it's not too hard to match your
> definition
> of plugin, it would be a win for me too as a user.

My objection is purely to the use of the name "Boost.Plugin" given 
what the library currently does. Even "Boost.BinaryLoader" is a 
better name.

> > > I don't see why ASIO would be a nice dependency for such a tool,
> > > but I don't understand what you mean either.
> >
> > ASIO is shortly to become the officially endorsed C++ event loop and
> > dispatcher. As event processing is by definition part of any plugin
> > or extension ABI - even if defined to be "no event processing", that
> > means ASIO.
> >
> I would prefer to be able to use any event loop implementation instead
> of forcing asio, personally, because it's not a depencency of my projects
> right now and I already have another event loop which is
> specifically designed for my case (and is not general at all and require a
> very specific impl, for a very specific feature).
> Basically I prefer composing library instead of using a library
> that assume that everybody uses the same event loop.
> I might be wrong though, I don't see the whole picture with asio yet.

Sorry, I didn't explain myself clearly: ASIO is the *master* event 
loop. All other event loops remain themselves, it's just that they 
can adapt into the master event loop which is ASIO. You can compose 
as many custom event loop implementations as you like, that's up to 
you.

This is possible because it turns out that ASIO's design is a 
superset of all other event loop designs I could find during when I 
researched this at BlackBerry. Therefore all other event loop designs 
can plug into ASIO with no loss of functionality, though with 
potential loss of low latency admittedly. I don't know if Chris 
intended this, but he achieved it nonetheless.

And of course because ASIO will enter the C++ standard, it'll simply 
be there in the STL all the time. No dependency problems (in the 
future).

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/