<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is there any benefit in keeping per-vendor plugins installed as<br>separate .so files and loaded during runtime?</blockquote><div>I think it'd be a shame to lose this architecture. On embedded</div><div>systems saving resources is always desirable and I remove</div><div>all vendor plugins that do not apply to an embedded hardware</div><div>footprint. The most common complaints that get raised to me to</div><div>avoid use MM for embedded systems is footprint. I'd hate to give</div><div>reasons to communities like OpenWRT to make a point out of that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thinking of installed size, I believe we may end up duplicating a lot<br>of code when plugins share common code, as the utils libraries are not<br>installed, they get incorporated in the plugins themselves. This also<br>makes some unexpected runtime errors if a plugin tries to register a<br>type that some other plugin has already registered (just had this one<br>today with the new Foxconn plugin in git master, which shares code<br>with the Dell plugin).</blockquote><div>Respectfully this just seems like poor plugin design. Why should it</div><div>be okay to create dependencies between plugins. Shouldn't shared</div><div>logic be in a share location if it really is common code? And if it's</div><div>shared but not applicable to all then maybe it should just be copied.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would bet there isn't any as we truly haven't kept a stable plugin<br>API like never ever.</blockquote><div>Ya but industrial users, for the worst, often tend to get a certain</div><div>version and stick with it. The API changing in that case doesn't matter.</div><div>With 5G on the door step there may be some new vendors that want to</div><div>have a proprietary plugin while they think their new API is god's gift</div><div>to humanity, cough cough hint hint. I love the GPL but losing the plugin</div><div>framework feels bad as someone who's had to deal with the bidding's</div><div>of mega-corp's and legal team's choices bases on lawyer bro's<br></div><div>understanding of software.</div><div><br></div><div>Cheers</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 15, 2019 at 8:10 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey,<br>
<br>
Is there any benefit in keeping per-vendor plugins installed as<br>
separate .so files and loaded during runtime?<br>
<br>
Does anyone know of any out-of-tree MM plugin out there? I would bet<br>
there isn't any as we truly haven't kept a stable plugin API like<br>
never ever.<br>
<br>
Thinking of installed size, I believe we may end up duplicating a lot<br>
of code when plugins share common code, as the utils libraries are not<br>
installed, they get incorporated in the plugins themselves. This also<br>
makes some unexpected runtime errors if a plugin tries to register a<br>
type that some other plugin has already registered (just had this one<br>
today with the new Foxconn plugin in git master, which shares code<br>
with the Dell plugin).<br>
<br>
What if we just simplify the setup and get all incorporated in the<br>
daemon binary itself (for MM 1.14 for example)?<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
_______________________________________________<br>
ModemManager-devel mailing list<br>
<a href="mailto:ModemManager-devel@lists.freedesktop.org" target="_blank">ModemManager-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel</a></blockquote></div>