emacs-devel
[Top][All Lists]
Advanced

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

Re: New patch for server sockets and datagram (UDP) support.


From: Alex Schroeder
Subject: Re: New patch for server sockets and datagram (UDP) support.
Date: Thu, 07 Mar 2002 12:39:07 +0100
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu)

address@hidden (Kim F. Storm) writes:

> Actually, I would like to get rid of this extra TYPE argument
> all together by modifying the HOST and SERVICE arguments in a 
> backwards compatible way (when calling open-network-stream):

Can you explain the benefit of such a change?  AFAICT, you described
the changes, discussed a potential problem, but there seemed to be no
advantages.  Personally, I like it when information is transmitted via
arguments instead of datastructures, ie. I prefer a TYPE argument to
encoding information in a cons cell (TYPE . SERVICE).

What about the comments by Mario and Helmut.  I think Mario wants to
implement DCC for an IRC client, and I think he needs to be able to
*not* specify a port.  Here's the quote from
http://www.irchelp.org/irchelp/rfc/ctcpspec.html:

        The initial socket for a DCC connection is created by the side
        that initiates (Offers) the connection. This socket should be
        a TCP socket bound to INADDR_ANY, listening for connections.

Other than that, I note that currently we have (open-network-stream
NAME BUFFER HOST SERVICE) and later we will have (open-network-stream
NAME BUFFER HOST SERVICE TYPE FILTER SENTINEL) or something
similar...  Since the function is the same, we cannot test using
boundp but will habe to use some condition-case in order to handle
XEmacs or older versions of Emacs, correct?

Perhaps splitting these things up into more functions might be easier
to understand and document.  One lisp function for one type of
functionality, instead of big black boxes to do it all.  If we still
want a blackbox, we could write it later using the two or three
existing functions.

Alex.
-- 
http://www.emacswiki.org/



reply via email to

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