On 11/17/2014 09:48 PM, Andrew Stitcher wrote:
On Mon, 2014-11-17 at 20:56 +0000, Gordon Sim wrote:
On 11/17/2014 08:14 PM, Andrew Stitcher wrote:
As we currently don't have reviewboard set up for Qpid Proton (since the
git migration).
I've posted a pull request against the Github Apache proton mirror to
get review feedback for my IO layer refactoring.
https://github.com/apache/qpid-proton/pull/1
Please give it some attention, I know that Rafi would like this change
to go in quickly as some important changes are queued up behind it.
I'm confused around the intention with regards to backward
compatibility. There seem to be changes that would break this, which is
entirely fine, but then old functions are retained but deprecated. If
the contract is indeed broken in some way, I think it would be better
not to retain functions that are no longer intended for use.
I don't think previously working code will stop working with these
changes (but I've not extensively tried). In other words I don't think
there is a broken contract at least not for pn_transport_t.
Previously there was no transport server/client distinction, which
effectively made the transport what is the current client transport
which is why that is the default.
As for pn_sasl_t. This now exactly follows the transport, so I guess
there is a possible broken contract.
The question is whether code that creates a transport without explicitly
choosing client or server, and then tries to set that as the sasl
server, will work (as it would have before).
In either case I'm very happy to remove the deprecated APIs - I have
left the change so this is trivially easy. Rafi suggested leaving them
in so I left them in.
In a similar vein for the python binding, for the Transport constructor,
I think it would be better to insist that either a c transport object or
a mode is provided, rather than defaulting to a client.
I'd be happy with this although as I said above the previous usage is
equivalent to the new client transport.
As above, if previous code would work, even for the server case, then I
have no issue. If it doesn't, then I think it is much clearer to remove
the old functions rather than trying to patch it up imperfectly.
If you feel strongly, and there is no dissent I will follow this advice.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
