Hi Andrew, > On Mon, 2009-12-14 at 20:13 -0500, Steve Huston wrote: > > Hi Andrew, > > > > I'll respond in more depth tomorrow, but for now I'd just > like to note > > that I'm not proposing to add a new transport - I just want > to stick a > > shim between the existing transport and the aio, on Windows only. > > Maybe we are talking at cross purposes, I'm not sure, surely > by definition adding a transport that was not previously > supported is adding a new transport regardless of the way you > do it.
It's adding a new feature, yes. > I think you are trying to argue that your strategy for > adding this new ssl transport is low risk. Exactly. > I'm arguing 2 things: > > 1. I don't think I like your strategy, but I'm not 100% clear > what it is exactly yet. The whole Connector layer is a shim > layer It's a pretty hefty shim. > so adding another shim seems to me to be likely to > complicate things and hinder refactoring clean ups to merge > the existing posix ssl and tcp transports into more maintainable code. I agree that refactoring a number of things would be The Right Thing to do. There's a lot of duplicate code between the current TCP connectors, the AIO layer, and the Linux/NSS-based SSL support. Looking at it, there are some fixes/features made to the TCP-base connector, for example, that weren't migrated to the NSS-based SSL support (such as read credit). I don't want to make this problem worse by doing another copy/paste/adjust. (Actually, I did that for the initial cut of client-side SSL support... I could go back in that direction to get this in for 0.6 if needed) Lacking the resources and the time schedule to refactor both Linux and Windows at this point, I came up with a middle ground to just open up the steps in the TCPConnector so I can insert a layer that knows to handle the SSL needs. It's specific to Windows and gets the job done until we can sensibly refactor other things. Note that when I did the original Windows port, this point that things needed refactoring also came up. I was convinced to not go that route, and that this area would be revisited at some point. That day hasn't come, and I'm not holding my breath for when it does. The way I was going about this is that the Windows-specific SslConnector reuses TCPConnector's frame-handling code - SslConnector does a couple things: - Puts an SslIo shim between itself and AsynchIO that knows to handle the SSL negotiation, and encrypt/decrypt operations - Waits to initiate the AMQP protocol until after the SSL negotiation is done > 2. I'm planning to put out a release candidate at the end of > the week and I don't want to destabilise existing well > working code in the next few days. Neither do I, which is why I avoided refactoring the AMQP frame-handling code out of TCPConnector, SslConnector, et al. Linux code gets left alone; the new code is for Windows and avoids risking Linux. > I'm sorry that windows ssl will not be in 0.6, but I'm very > open to making the 0.7 release cycle very short if there are > features that people want to release very soon. It is rather important to get this into 0.6, but let me confer with the powers that be and see what we can do. > All that being said I'd be keen to see your proposed code for > review before checkin. I'll make a new jira for it when I have code ready (which should be today). -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
