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(a)jcline.org> 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(a)jcline.org
> IRC: jcline