Nice write up.
When you say:
<snip>
The consumer framework also receives messages for actions via gofer, passing them off to
the appropriate plugins. When plugins register themselves, one of the important pieces of
information they provide will have to be what gofer messages/actions they are meant to
handle.
</snip>
Are you suggesting the pulp gofer/pulpplugin dispatch RMI to a consumer framework plugin?
If so, wouldn't it make more sense to split up the gofer/pulpplugin into several gofer
plugins that are each contributed by a client framework plugin RPM? The contributed gofer
plugin could still call into the client framework plugin's modules to do the heavy lifting
but we could avoid the extra registration/dispatch mechanism.
On 07/20/2011 01:59 PM, James Slagle wrote:
I've put up a wiki page about the client refactoring stuff I'm working on.
It's at:
https://fedorahosted.org/pulp/wiki/ClientRefactoring
I've gotten some initial feedback from jdob and have revised it a bit to
incorporate those changes. Please review it when you have a moment and
feel free to send me any feedback.
Thanks.
--
-- James Slagle
--
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
