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. 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. 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]
