Daniel Wippermann wrote:
> Hi,
>
>> we could actually eliminate the need for creating a nsIServerSocket
>> interface by just using nsIRequest.
>>
>> nsIRequest::status - current status, NS_FAILED if there was a problem
>> nsIRequest::isPending - TRUE if polling for incoming connections
>> nsIRequest::cancel - to stop polling
>> nsIRequest::suspend - to temporarily stop polling
>> nsIRequest::resume - to resume polling after being suspended
>> nsIRequest::loadGroup - ignored
>> nsIRequest::loadFlags - ignored
>>
>> then, we'd have something like this:
>>
>> nsISocketTransportService {
>> // ...
>> nsIRequest createServerSocket(in long port,
>> in nsIServerSocketListener listener,
>> in nsISupports ctxt);
>> };
>
>
>
> The disadvantage is that the I/O layers like SSL or SOCKS (as suggested
> by Bradley Baetz) can only hardly be integrated using nsIRequest. So we
> have to decide if we do it light-weight or flexible...
>
we should be fine if we just provide variants on createServerSocket. i
don't see why we need a special interface such as nsIServerSocket...
what doesn't nsIRequest provide?
also, i don't understand how proxy info makes any sense for server
sockets. i understand that that's how we currently convey SOCKS info
down to the client sockets, but for server sockets it just seems out of
place to talk of proxies.
darin
