PR_NewUDPSocket vs PR_OpenUDPSocket

Working with NSPR documentation available on Mozilla's wiki, we've come to an issue with PR_NewUDPSocket been deprecated. PR_OpenUDPSocket is suggested to be used instead. Currently LSB is going to include PR_NewUDPSocket and not PR_OpenUDPSocket. Are there any reasons that would prevent us from including PR_OpenUDPSocket and dropping PR_NewUDPSocket? -- Regards, Denis.
PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Wan-Teh Chang on Thu, 11/13/2008 - 18:30.

On Thu, Nov 13, 2008 at 2:38 AM, Denis Silakov wrote:
> Working with NSPR documentation available on Mozilla's wiki, we've come to
> an issue with PR_NewUDPSocket been deprecated. PR_OpenUDPSocket is suggested
> to be used instead.
>
> Currently LSB is going to include PR_NewUDPSocket and not PR_OpenUDPSocket.
> Are there any reasons that would prevent us from including PR_OpenUDPSocket
> and dropping PR_NewUDPSocket?

Both PR_NewUDPSocket and PR_OpenUDPSocket are supported functions.
The only difference between these two functions is that PR_NewUDPSocket
is hardcoded to use the PR_AF_INET (IPv4) address family, whereas
PR_OpenUDPSocket allows the caller to specify the address family.
This is why PR_OpenUDPSocket is preferred and PR_NewTCPSocket is
marked as "deprecated" in the documentation.

If "deprecated" is the wrong word to indicate the status of PR_NewTCPSocket,
I'll be happy to use a more accurate word that is less likely to be
misunderstood.

I remember I recommended that LSB include PR_OpenUDPSocket.
Why do you want to include PR_NewUDPSocket and not PR_OpenUDPSocket?
It'd be better to include only PR_OpenUDPSocket, or both of them.

Wan-Teh

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Denis Silakov on Fri, 11/14/2008 - 08:15.

Thanks, Wan-Teh.

> If "deprecated" is the wrong word to indicate the status of PR_NewTCPSocket,
> I'll be happy to use a more accurate word that is less likely to be
> misunderstood.
>

Well, usually 'deprecated' word means that developers plan to drop the
function in the future. LSB doesn't tend to include such functions.
Surely, this is not the strict rule, I know some other cases when a
function is called 'deprecated' just because it has more functional
analogue (as PR_NewUDPSocket), though there are no plans for dropping
it. So I think 'deprecated' word is ok here.

In any case, there is no reason to include a function in LSB if it has a
better analogue, just not to make the specification too large.

> I remember I recommended that LSB include PR_OpenUDPSocket.
> Why do you want to include PR_NewUDPSocket and not PR_OpenUDPSocket?
> It'd be better to include only PR_OpenUDPSocket, or both of them.
>

It seems that there was some misunderstanding with lists of symbols,
since currently PR_OpenUDPSocket is not included. We'll fix this.

--
Regards,
Denis.

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Wan-Teh Chang on Fri, 11/14/2008 - 19:15.

On Fri, Nov 14, 2008 at 12:08 AM, Denis Silakov wrote:
>
>> I remember I recommended that LSB include PR_OpenUDPSocket.
>> Why do you want to include PR_NewUDPSocket and not PR_OpenUDPSocket?
>> It'd be better to include only PR_OpenUDPSocket, or both of them.
>>
>
> It seems that there was some misunderstanding with lists of symbols, since
> currently PR_OpenUDPSocket is not included. We'll fix this.

Yes, I just looked up the list of functions I recommended for inclusion
in LSB 4.0: https://developer.mozilla.org/En/NSS_reference/NSPR_functions

I was instructed to provide the absolute minimal list of NSPR functions
that people need to use NSS successfully. Under that guideline, the
list I provided is draconian. It doesn't have PR_NewTCPSocket or
PR_NewUDPSocket, not to mention PR_NewUDPSocket or
PR_OpenUDPSocket. (SSL/TLS doesn't use UDP sockets.)

So it seems that you're including some additional NSPR functions
that are not on my list. Actually I prepared a second list of additional
NSPR functions that would make the NSPR functions in LSB more
complete. I didn't send that list to the LSB. Here it is:

PR_OpenTCPSocket
PR_Bind
PR_Listen
PR_Accept
PR_Connect
PR_ConnectContinue
PR_Poll
PR_GetAddrInfoByName
PR_EnumerateAddrInfo
PR_FreeAddrInfo
PR_StringToNetAddr
PR_NetAddrToString

PR_GetCurrentThread
PR_Interrupt

Note that PR_OpenUDPSocket is still not on this list because UDP is not
required by SSL/TLS. (I certainly support adding PR_OpenUDPSocket to
the LSB, but you'd need to add PR_SendTo and PR_RecvFrom to go with
it.)

Wan-Teh Chang

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Denis Silakov on Mon, 11/17/2008 - 09:15.

Wan-Teh Chang wrote:
> So it seems that you're including some additional NSPR functions
> that are not on my list. Actually I prepared a second list of additional
> NSPR functions that would make the NSPR functions in LSB more
> complete. I didn't send that list to the LSB. Here it is:
>
> PR_OpenTCPSocket
> PR_Bind
> PR_Listen
> PR_Accept
> PR_Connect
> PR_ConnectContinue
> PR_Poll
> PR_GetAddrInfoByName
> PR_EnumerateAddrInfo
> PR_FreeAddrInfo
> PR_StringToNetAddr
> PR_NetAddrToString
>
> PR_GetCurrentThread
> PR_Interrupt

Hmm. It seems that NSPR wiki doesn't provide any descriptions for
PR_GetAddrInfoByName, PR_EnumerateAddrInfo and PR_FreeAddrInfo.

--
Regards,
Denis.

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Wan-Teh Chang on Wed, 11/19/2008 - 00:00.

On Mon, Nov 17, 2008 at 1:09 AM, Denis Silakov wrote:
>
> Hmm. It seems that NSPR wiki doesn't provide any descriptions for
> PR_GetAddrInfoByName, PR_EnumerateAddrInfo and PR_FreeAddrInfo.

Sorry about that. They're documented in the NSPR wiki now:
https://developer.mozilla.org/En/NSPR_API_Reference/Network_Addresses#Ne...

Wan-Teh Chang

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Denis Silakov on Wed, 11/19/2008 - 12:15.

Wan-Teh Chang wrote:
> Sorry about that. They're documented in the NSPR wiki now:
> https://developer.mozilla.org/En/NSPR_API_Reference/Network_Addresses#Ne...

Thanks.

--
Regards,
Denis.

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Denis Silakov on Mon, 11/17/2008 - 09:15.

Thanks, Wan-Teh. We'll rearrange the set of nspr functions in LSB to
match the new list.

> So it seems that you're including some additional NSPR functions
> that are not on my list. Actually I prepared a second list of additional
> NSPR functions that would make the NSPR functions in LSB more
> complete. I didn't send that list to the LSB. Here it is:
>
> PR_OpenTCPSocket
> PR_Bind
> PR_Listen
> PR_Accept
> PR_Connect
> PR_ConnectContinue
> PR_Poll
> PR_GetAddrInfoByName
> PR_EnumerateAddrInfo
> PR_FreeAddrInfo
> PR_StringToNetAddr
> PR_NetAddrToString
>
> PR_GetCurrentThread
> PR_Interrupt
>
> Note that PR_OpenUDPSocket is still not on this list because UDP is not
> required by SSL/TLS. (I certainly support adding PR_OpenUDPSocket to
> the LSB, but you'd need to add PR_SendTo and PR_RecvFrom to go with
> it.)

--
Regards,
Denis.

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Wichmann Mats D on Fri, 11/14/2008 - 23:30.

Wan-Teh Chang wrote:

> Note that PR_OpenUDPSocket is still not on this list because UDP is
> not required by SSL/TLS. (I certainly support adding
> PR_OpenUDPSocket to
> the LSB, but you'd need to add PR_SendTo and PR_RecvFrom to go with
> it.)

Actually, those are in, I just checked the list.

PR_NewUDPSocket vs PR_OpenUDPSocket - Submitted by Wan-Teh Chang on Fri, 11/14/2008 - 19:15.

I'd like to correct a typo in my previous message. When referring
to the list of NSPR functions I recommended for LSB 4.0 at
https://developer.mozilla.org/En/NSS_reference/NSPR_functions

I said:
It doesn't have PR_NewTCPSocket or PR_NewUDPSocket,
not to mention PR_NewUDPSocket or PR_OpenUDPSocket.

That sentence should read
It doesn't have PR_NewTCPSocket or PR_OpenTCPSocket,
not to mention PR_NewUDPSocket or PR_OpenUDPSocket.

Wan-Teh Chang

Copyright © 2008 Linux Foundation. All rights reserved.
LSB is a trademark of the Linux Foundation. Linux is a registered trademark of Linus Torvalds