External plugins? No. We are talking about internal modular interfaces used to separate the code conceptually. This allows us to delegate data collection easily to domain experts. It also allows users to choose, somewhat coursely, which day they report. For example, some users may be fine with submitting hardware but not a list of their installed packages. Dividing the data cleanly enables this. On Wed, Nov 8, 2017 at 3:59 PM, Jeremy Cline <jeremy@xxxxxxxxxx> wrote: > On 11/08/2017 03:18 PM, Nathaniel McCallum wrote: >> I agree completely. My point is not that we don't need any planning, >> but that the planing is scoped per plugin. > > Do we really need the concept of plugins, though? Are there going to be > plugins that live outside of the census "core"? Will users want to mix > and match plugins? Are all the plugins combined more than most users > want to install? I don't feel like the answer to any of those questions > is "yes". > > I'm all for defining solid internal interfaces so it's easy to extend, > and I expect users will want to be able to limit what they send in > (maybe just hardware and no software report), but neither of those > things seem like they require plugins. > > Perhaps I'm being short-sighted. I wasn't around for Smolt and so it's > hard for me to know all the pain-points of its design. It just seems to > me that scoping planning to individual pieces of the system is going to > lead to a whole bunch of disconnected buckets of data that won't be > pleasant to work with. > > > -- > Jeremy Cline > XMPP: jeremy@xxxxxxxxxx > IRC: jcline > _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
