[sos-devel] s/plugin/module/g?

[Jesse Jaggars]

On 02/08/2012 02:18 PM, Bryn M. Reeves wrote:
> On 02/08/2012 08:07 PM, Jesse Jaggars wrote:
>> I can see a small benefit in calling them modules, since they literally
>> are python modules. My only reservation would be that module doesn't
>> really explain what purpose they serve, although plugin is just as bad.
> Right :)
>
> I find myself using module as a least-worst kind of thing.
>
>> I have been operating under the assumption that the 'plugin' interface was
>> intended to be stable. I did make alterations, but I also believe we should
>> bump the major version number to reflect the change.
> I think there are two problems with the interface as it stands: in the
> past it's never really been well-defined or had guarantees and because
> of the way the plugins operate we've sometimes had to make changes
> across whole sets of files in updates. Out of tree modules make that
> even more complex as you have to chase them down and get updates there too.
>
> The other problem is that the plugins also create an interface to
> consumers of the data. This has the same problem with definition (or a
> lack of it) but that's something we've already talked about improving.
Ah I agree that these are both issues with the current system. At the 
implementation level there are several ugly bits about the interface 
between a plugin/module subclass and the superclass. Those could be 
ironed out and cleaned up, but I'm not sure if just tweaking the current 
'api' is the best thing or not. I do think that if we ever want to widen 
support for sosreport beyond the redhat/fedora/jboss world we will have 
to present a stable API for folks to use.

The outbound interface is a tough problem for sure, but I think it's 
such a different issue that it has to be handled in a completely 
different conversation (though it is certainly just as important and 
valuable).
>> In terms of pure terminology, I don't think plugin is a better or worse term
>> than module, so either term is acceptable to me.
> No strong attachments here either apart from the connotations of plugin
> but I can't think of anything better so far..
Today we now have a policy 'api' for defining how to work with other 
distributions and operating systems. I have simply been calling those 
policies. I can't summon up a better term for what we have been calling 
a plugin either.
> Cheers,
> Bryn.
Jesse