On Thu, Mar 04, 2004 at 04:26:10PM -0600, Nicholas Perez wrote: > Okay, I glanced at the code and read through the ml archives regarding > sslpoe and how there seems to be a dilema revolving around where to put > this working code. Everyone is concerned since it isn't a wheel, filter, > driver, component, etc etc. Well let's look at what it is doing. It is > directly working on the socket. In the ClientTCP example code, the > socket is tied to bits before it even gets to the wheel... but nothing > happens inbetween that. What do wheels do? Manage the socket given to > them through filters and drivers. If they manage the socket why not push > this SSL functionality (the tied class) into ReadWrite? Have it be a > hidden class because there is no need to expose this functionality > outside of the wheel. And you could even do it two ways: have it be an > extra argument passed at creation time or even a simple > $wheel->toggle_ssl() for midstream negotiation to kick in. Ideally the > end developer shouldn't need to worry about the SSL stuff at all, so > let's just put it into the wheel and let the poor developer get back to > worrying about handling the data coming down the pipe.
My major reluctance to include SSL features into Wheel::ReadWrite is that it leads to a monolithic reader/writer thing that everything gets dumped into. This leads to a new ReadWrite method or every tied filehandle class that comes along. That's really messy. I'd rather see something that can support any tied filehandle class that might come along. It may be as simple as (finally) exposing the filehandle for people to muck with. Rather than add a filehandle accessor to the wheel, it might be more robust to have methods that release and retake it. That way the wheel can ensure a filehandle is in a proper state after it's been mucked with. -- Rocco Caputo - http://poe.perl.org/
