Built-in plugins?

[Dan Williams]

On Sun, 2019-11-17 at 15:16 +0100, Aleksander Morgado wrote:
> > > Is there any benefit in keeping per-vendor plugins installed as
> > > separate .so files and loaded during runtime?
> > 
> > I think it'd be a shame to lose this architecture. On embedded
> > systems saving resources is always desirable and I remove
> > all vendor plugins that do not apply to an embedded hardware
> > footprint. The most common complaints that get raised to me to
> > avoid use MM for embedded systems is footprint. I'd hate to give
> > reasons to communities like OpenWRT to make a point out of that.
> > 
> > > Thinking of installed size, I believe we may end up duplicating a
> > > lot
> > > of code when plugins share common code, as the utils libraries
> > > are not
> > > installed, they get incorporated in the plugins themselves. This
> > > also
> > > makes some unexpected runtime errors if a plugin tries to
> > > register a
> > > type that some other plugin has already registered (just had this
> > > one
> > > today with the new Foxconn plugin in git master, which shares
> > > code
> > > with the Dell plugin).
> > 
> > Respectfully this just seems like poor plugin design. Why should it
> > be okay to create dependencies between plugins. Shouldn't shared
> > logic be in a share location if it really is common code? And if
> > it's
> > shared but not applicable to all then maybe it should just be
> > copied.
> > 
> 
> You're right, that was indeed poor plugin design. Up until now we
> were
> "copying" as you said, but that would break the GType system when
> multiple plugins tried to create objects of the same type. I've tried
> to fix the plugin design my creating a new set of installed modules
> that provide the shared utils to the plugins, please see:
> 
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209
> 
> Due to the copy no longer being done, the overall size of all .so
> files installed in /usr/lib/ModemManager went from 7MB to 5.5MB in my
> machine, even with the new shared modules installed. Comments
> welcome!
> 
> > > I would bet there isn't any as we truly haven't kept a stable
> > > plugin
> > > API like never ever.
> > 
> > Ya but industrial users, for the worst, often tend to get a certain
> > version and stick with it. The API changing in that case doesn't
> > matter.
> > With 5G on the door step there may be some new vendors that want to
> > have a proprietary plugin while they think their new API is god's
> > gift
> > to humanity, cough cough hint hint. I love the GPL but losing the
> > plugin
> > framework feels bad as someone who's had to deal with the bidding's
> > of mega-corp's and legal team's choices bases on lawyer bro's
> > understanding of software.
> > 
> 
> As long as they don't update the ModemManager version, that would
> work. But note that not even stable MM updates (e.g. 1.10.0->1.10.2)
> the plugin API is maintained. Of course, if they are the ones
> building
> MM as well, that's a different story, but then I wouldn't call that
> an
> external plugin, it really would be a totally different MM in my
> opinion. The fact that it's developed as a plugin doesn't make it a
> "proper plugin" if you know what I mean.

Another option to address Matthew's concern would be compile-time
selectable plugins. We would still keep the general plugin architecture
(eg the concept of separate/encapsulated code modules for each type of
hardware) since I think that's a good thing to do from a software
engineering and architecture point of view. But if you wanted to, you
could pass --enable-plugins=X,Y,Z or something and end up with a
smaller binary.

Dan