I seem to remember wanting similar functionality in the past and it
was countered for some reason. A wheel would be useless without the
handles (ie, yanked out via accessor), but it keeps the end developer
from holding onto a reference to the handles when building the wheel
in the first place.
On 5/23/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
The component wouldnt be the one to provide access to it.
You would need to patch POE::Wheel::ReadWrite to provide an accessor
method to the input and output handles.
On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
>
> I need access to the socket, as I have to use the getsockopt
> call. I don't have any problems with using SocketFactory and
> Wheels for my server. Just though it would be nice if
> PoCo::Server::TCP does provide access to the socket.
>
> Thanks,
> Rohan
>
> Matt Sickler wrote:
> > There arent any documented ways to get at a ReadWrite wheel's handle.
> > The non-POE way you could do it (and breaking encapsulation) would be to
> > use
> > $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_INPUT ] and
> > $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_OUTPUT ]
> > ( those would be the same in many situations ).
> > This breaks encapsulation and could change at no notice and its all your
> > fault.
> >
> > A better question you need to ask is why do you need to get at the socket?
> >
> > On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi,
> >>
> >> Is there any way I can get access to the underlying socket while
> >> using PoCo::Server::TCP without using the Client* callbacks?
> >>
> >> The docs say that the socket is only passed if I use the Acceptor
> >> callback, which then means I have to create my own Wheel for
> >> read/write and so on.
> >>
> >> Again, $heap->{listener} is only available if I use the Acceptor
> >> callback. $heap->{client} seems to be a ReadWrite wheel. I tried
> >> accessing the Handle for this wheel (which should be the socket),
> >> but I'm not getting anywhere.
> >>
> >> Thanks,
> >> Rohan
> >>
> >>
> >
>
>
