From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Alex Schroeder Newsgroups: gmane.emacs.devel Subject: Re: New patch for server sockets and datagram (UDP) support. Date: Thu, 07 Mar 2002 12:39:07 +0100 Message-ID: <874rjsd2uc.fsf@gnu.org> References: <5xwux64cxe.fsf@kfs2.cua.dk> <5xg03pyyo3.fsf@kfs2.cua.dk> <5xadtvuodz.fsf@kfs2.cua.dk> <200202280408.g1S48QG19264@aztec.santafe.edu> <5xvgchkui4.fsf@kfs2.cua.dk> <200203012123.g21LNvS20494@aztec.santafe.edu> <5xofi1p7cz.fsf_-_@kfs2.cua.dk> <5xg03cprxi.fsf@kfs2.cua.dk> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1015501650 7454 195.204.10.66 (7 Mar 2002 11:47:30 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 7 Mar 2002 11:47:30 GMT Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16iwMr-0001w8-00 for ; Thu, 07 Mar 2002 12:47:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16iwEv-0002Xu-00; Thu, 07 Mar 2002 06:39:17 -0500 Original-Received: from relay01.cablecom.net ([62.2.33.101]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16iwDO-0002TV-00 for ; Thu, 07 Mar 2002 06:37:42 -0500 Original-Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay01.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id g27Bbe243225 for ; Thu, 7 Mar 2002 12:37:40 +0100 (CET) Original-Received: from confusibombus (dclient217-162-121-162.hispeed.ch [217.162.121.162]) by mail.swissonline.ch (8.11.4/8.11.4/MSOL-2.30/21-Dec-2000) with ESMTP id g27Bbe223174 for ; Thu, 7 Mar 2002 12:37:40 +0100 (MET) Original-Received: from alex by confusibombus with local (Exim 3.12 #1 (Debian)) id 16iwEl-0000Cj-00 for ; Thu, 07 Mar 2002 12:39:07 +0100 Original-To: emacs-devel@gnu.org X-Face: ^BC$`[IcggstLPyen&dqF+b2'zyK#r.mU*'Nms}@&4zw%SJ#5!/7SMVjBS7'lb;QK)|IPU5U'o1'522W4TyzB3Ab*IBo^iw]l4|kUbdZuUDO6=Um-.4IzhNiV'B"@K#jy_(wW|Zbk[34flKY^|PrQ?$u2\fKg^]AY>wOX#H32i In-Reply-To: <5xg03cprxi.fsf@kfs2.cua.dk> (storm@cua.dk's message of "07 Mar 2002 11:56:25 +0100") Original-Lines: 37 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1778 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1778 storm@cua.dk (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/ _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel