emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: :family extension for make_network_process


From: Kim F. Storm
Subject: Re: :family extension for make_network_process
Date: Mon, 12 Dec 2005 15:07:06 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Kazu Yamamoto (山本和彦) <address@hidden> writes:

> Hello, 
>
> I would report one documentation mistake and propose an extension for
> make_network_process.

I looked at your patch, and I cannot get it to fit precisely to what
you describe below:

>
> DOC: 
>
> Recently many OSes have implemented getaddrinfo. In this case, AF_UNSPEC
> is used. Thus, the documentation of the :family arguments should be
>       "The default address family is IPv6 or IPv4"

Better would be:

The default address family is one of IPv4 or IPv6 depending on what
the name server returns as the primary address for the host.


> instead of
>       "The default address family is Inet (or IPv4)".
>
> EXTENSION:
>
> Since nil for :family cannot ensure to choose IPv4, 

It can!  The default family is used only if :family is NOT present,
whereas :family nil means AF_INET.  So only inet6 is really needed.

In any case, your interface is probably better for clarity.  So:

:family nil == :family omitted == use default
:family 'ipv4 => force IPv4
:family 'ipv6 => force IPv6

I think it is clearer to use ipv4 and ipv6 rather than inet and inet6.

>                                                     I would propose
> two more symbols for the :family arguments:
>       'inet for IPv4
>       'inet6 for IPv6
>
> Note the :family arguments: can take an integer but it is not
> practical to tell the value of AF_INET (or AF_INET6) from the Elisp
> level in ALL environments.

True -- this is intended as a "low-level" interface to allow the use of
"other address families" which are not known to emacs.

> The following is a sample code to implement this. Please merge this
> code if possible.

Thanks for the patch, but I will implement it a little differently.
And update the documentation accordingly...

-- 
Kim F. Storm <address@hidden> http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]