On 07/17/11 15:14, [email protected] wrote:
> Thus, for me, it makes sense to identify the incoming message with
> in_message.get_namespace() rather than with self.get_tns().
> For now, we can't specify a different namespace for the input message type
> definition, so both methods give the same result.
>
> I'm not sure that this feature is really necessary. I'd like to have it
> because I'm using soaplib to create a stub for a WS which for I have the wsdl
> but can't access to it right now. It is absolutely useless if you build your
> WS with soaplib and use the "auto-generated" wsdl.
>
I think this feature is necessary. But, how do you think the api should
work? Would you be OK with adding an additional "_{in,out}_message_ns"
argument to the @rpc decorator?
> -----
>
> Also, i would like to contribute to another improvement :
> - at the moment, the in_header and out_header are composed of a single
> element, but the specification authorize multiple elements in the soap
> header. This is already managed by suds (you can affect a tuple to the
> soapheaders option), and is commonly used to distinguish the different kind
> of headers (authentication header, message identifier header, trace header,
> ...)
>
> So, I-d like to modify the use of __in_header__, __out_header__, _in_header,
> _out_header, ... to authorize either a single model, or a tuple/list of
> models.
>
I think this feature is also necessary, and I'd love to see a patch.
> What is the best way for me to contribute to this (if you agree) : should I
> have to fork the soaplib project or your rpclib project ? What is the
> relationship between the two projects ?
>
I wrote most of what soaplib is today. rpclib is in fact soaplib-3.0,
see the change log here:
https://github.com/arskom/rpclib/blob/master/CHANGELOG. It's also what
i'm going to be working on in the future. There was a plan to move soap
code from rpclib to soaplib, but this is not a priority task in my to-do
list.
There are two issues with rpclib as it is:
1) The protocol api is not well-tested -- it might need changes in the
future.
2) The documentation is seriously out-of-date.
... hence the alpha tag in its versions. Otherwise it's stable (both in
terms of application api and code maturity) as a soap server.
those said, i'd prefer you to contribute to rpclib, because i'm going to
have to port your patches to rpclib anyway if you contribute to soaplib.
i hope that helps.
best regards,
burak
_______________________________________________
Soap mailing list
[email protected]
http://mail.python.org/mailman/listinfo/soap
