This is a very interesting proposal, and it would be really great if you
could file a bugzilla bug describing your solution. Please add the
prefix RFE to the beginning of the summary, so we'll know that this is a
'requested feature enhancement.' Also, feel free to submit a patch :-)
nsISocketTransport is not a frozen interface.
Darin
Daniel Wippermann wrote:
> Hi Doug,
>
>> There has been no formal proposal or work done in this area. If you
>> or anyone is interested, I can help.
>
>
>
> I'd appreciate your help. I think that server socket support could be
> a useful extension to the existing necko.
>
> In my opinion the best way to implement this support is to extend the
> nsISocketTransport interface with new function called e.g.
> "asyncAccept". This function could take the following parameters:
>
> 1) a string containing hostname to bind to (could be "0.0.0.0" to bind
> to any address)
>
> 2) a port number to bind to
>
> 3) a backlog value needed for PR_Listen
>
> 4) an pointer to a listener interface receiving the accepted socket (I
> don't know if there is already an existing interface that fits ours
> need, if not we'll have to create a new one)
>
> 5) a context interface pointer as used by the nsITranpsort::async????
> functions
>
> 6) proxying flags for the listener interface as used by the
> nsITransport::async???? functions
>
> Calling this function could lead into creating a new socket, binding
> it to the specified address and calling PR_Listen. Afterwards the
> socket would be added to the work queue of the socket transport
> service. As soon as a connection attempt is detected, the PR_Poll
> would return with a read event for the server socket. The
> nsSocketTransport's Process() would create a new nsSocketTransport
> object and assign the accepted socket's file descriptor to this
> object. So far, so good...
>
> The big question for me (being a newbie working on mozilla since one
> week :-) is whether I am allowed to extend the nsISocketTransport
> interface. I tried implementing server sockets as a socket provider
> service in the first place, but realized very soon, that this is not
> the right place, since I cannot assign the accepted socket to a
> nsSocketTransport object without making modifications there.
>
> Any discussion about this proposal is welcome...
>
> Daniel
>
