On Thursday 13 May 2010, Jeff Ortel elucidated thus: Initial comments (just clarification, mostly). - Clarify in the docs exactly when the hooks get called, and what they contain. "After client is initialized." OK, but what (loosely) has happend at that point? And before *what*? What is the WSDL object? The raw file (object)? The response from urllib2.urlopen()? - Same for "loaded." What does "loading" a WSDL or XSD entail? Opening? Parsing? It says "contains the document root." But: loaded: "called before loading"..."contains document root" Sounds like it's called after something is loaded...the name is confusing. "Sending" and "received" seem clear enough. I'm sure I'll have more comments...those were the ones that struck me first. j -- Joshua Kugler Part-Time System Admin/Programmer http://www.eeinternet.com PGP Key: http://pgp.mit.edu/  ID 0x73B13B6A

Hi, I have read the proposal and the initial comments and here below my personal view. -- Your plugin scheme is generic enough to try to handle everything, but I think that different planes of execution are being mixed, and even with the subclassing approach things can get mixed. I see the following different planes: - Initialization - Loading - Anything to do with invoking a SOAP method Therefore there would be three different types of plugins. To tackle such a problem and make things simple, instead of a plugin object, the user of suds could insert callables at each defined filter point like in this example: myclient.filter.addcallable(SENDING, mycallable) Using a callable enables passing functions or objects that define the __call__ method, which adds a layer of generalization. Each callable would then receive an object with at least the following attributes: - filterPoint (SENDING, LOADING, etc ...) - data One callable could handle more than one event if wished. After all the above, let me say that the object approach is also good enough for me and I would graciously accept it as a very nice addition to suds. I would anyhow add some more entry points: - AFTER_PROCESSING_REPLY XML text has been received, processed and converted to the response object. For whatever the reason, a plugin may choose to examine and/or change the objects or the content of the objects - BEFORE_CREATING_ENVELOPE Again, inspecting/changing the objects before they are converted to the SOAP envelope may be wished. Nicely thought Jeff Best regards Daniel On Thu, May 13, 2010 at 21:14, Jeff Ortel <jortel(a)redhat.com&gt; wrote:

Hey Daniel, Thank you very much for your thoughtful comments. See inline. -jeff On 05/14/2010 12:50 PM, Daniel Rodriguez wrote: I think "simple" here depends on how object oriented you are :) Fundamentally you are proposing two things: [1] Provide for registering callables in addition to Plugin objects. The objective seems to be to allow procedural programmers to pass functions. [2] Scope what you are registering by where it is registered (filter) "filter.addcallable()" and by passing a constant "SENDING". I don't have much sympathy for [1]. Sorry. Because the callable needs to have IF/ELSE logic around what it is filtering. And, if doing any real work *should* delegate to another function do deal with it (functions/methods should do 1 thing). This seems simpler: def MyPlugin(Plugin): def sending(context): ... def received(context): ... then: def filter(what, data): if what == 'SENDING': sending(data) elif what == 'RECEIVED': received(data) else: raise Exception, "..." def sending(data): ... def received(data): ... Also, [1] adds complexity to the registration. This seems simpler for user (and suds internal): client = Client(url, plugins=[a,b,c]) Than: client = Client(url) myclient.filter.addcallable(SENDING, foo) myclient.initialiation.addcallable(bar) myclient.loading.addcallable(fn) I like a lot of what you are proposing in [2] because it address something that I'm struggling with. That is, how to name the plugin API methods. You're correct in that my approach so far seems too broad. Because the plugin API covers everything the method names should be almost a full sentence long (but that would be excessive). Your suggestion of plugin types provides much needed scoping. Perhaps the Plugin (abstract class) should be split into multiple classes based on the plugin's function? That would provide scoping for the method names and keep the purpose of each plugin more narrowly focused. Maybe something like: class InitPlugin: def initialized(context) : pass class MessagePlugin: def creating(context) : pass <-- creating soap envelope based on passed info. def sending(context): pass <-- sending soap envelope. def received(context) : pass <-- received raw reply text. def parsed(context) : pass <-- sax parsed reply def returning(context) : pass <-- object being returned. class DocumentPlugin: def parsed(context) : pass <-- parsed() more descriptive then loaded() Basically, MessagePlugin.sending() == filter.addcallable(SENDING, mycallable) with regard to scoping. I chose the MessagePlugin rather then something like FilterPlugin because 'filtering' seemed too broad as well. If taking this approach, It would probably make sense to have a 'Context' per plugin type. The context for MessagePlugin(s) could/should probably be: MessageContext * method <-- method name * params <-- parameters passed. * envelope <-- outgoing envelope XML document root. * reply <-- depends on how called: received() : reply = raw text parsed() : reply = sax parsed reply returning(): reply = object being returned. Thoughs? Comments? Is this any better? Am I smoking crack? Yes. Seems useful. I don't see much value here because the user (you) passed the parameters in the first place but I'm not opposed to adding it. Thanks! Again, I really appreciate you taking the time to review and offer you helpful comments.

On 05/20/2010 11:32 AM, Joshua J. Kugler wrote: Thanks for the feedback Joshua. The context is not really meant to be just a wrapper for parameters to the plugin methods but to provide context around the event in which the plugin is participating. In this way, I'd expect the context to be cumulative. I expected to populate the fields in natural progression: All methods: * method <- name of method (web server operation) being invoked. for created() add (params). Now context has: * method * params for sending() add (envelope). Now context has: * method * params * envelope for received(), parsed() and returning() add (reply). Now context has: * method * params * envelope * reply