Built-in plugins?

[matthew stanger]

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

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.

Cheers

On Fri, Nov 15, 2019 at 8:10 AM Aleksander Morgado <aleksander at aleksander.es>
wrote:

> Hey,
>
> Is there any benefit in keeping per-vendor plugins installed as
> separate .so files and loaded during runtime?
>
> Does anyone know of any out-of-tree MM plugin out there? I would bet
> there isn't any as we truly haven't kept a stable plugin API like
> never ever.
>
> 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).
>
> What if we just simplify the setup and get all incorporated in the
> daemon binary itself (for MM 1.14 for example)?
>
> --
> Aleksander
> https://aleksander.es
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20191115/6c01e28d/attachment-0001.html>