Built-in plugins?

[Aleksander Morgado]

>> 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.

-- 
Aleksander
https://aleksander.es