From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: New patch for server sockets and datagram (UDP) support. Date: 07 Mar 2002 13:39:50 +0100 Message-ID: <5xbse0pn55.fsf@kfs2.cua.dk> 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> <874rjsd2uc.fsf@gnu.org> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1015505222 9798 195.204.10.66 (7 Mar 2002 12:47:02 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 7 Mar 2002 12:47:02 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16ixIT-0002Xp-00 for ; Thu, 07 Mar 2002 13:47:01 +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 16ixAq-0008HE-00; Thu, 07 Mar 2002 07:39:08 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.33 #1 (Debian)) id 16ixAW-0008GT-00; Thu, 07 Mar 2002 07:38:49 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id 3C5247C047; Thu, 7 Mar 2002 12:38:47 +0000 (GMT) Original-To: Alex Schroeder In-Reply-To: <874rjsd2uc.fsf@gnu.org> Original-Lines: 86 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 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:1780 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1780 Alex Schroeder writes: > 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). Yes, that is the other route we can take - and then also split the current TYPE argument into TYPE and FAMILY. I have absolutely no objections to doing that -- actually, that it what I originally wanted to do, but then I was told that open-network-stream has too many arguments already... So expect to see 8 arguments in the next version :-) > > 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. Ok, I'll add that. The selected port number will be available in (cadr (process-contact ddc)) (i.e. the SERVICE element). > > 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? Although not very obvious, you can use (boundp 'network-server-log-function) to test for server socket support. And you can use (fboundp 'process-datagram-address) to test for datagram support [if I change the code so that this function is only available when DATAGRAM_SOCKETS is defined.] Alternatively, using something like (featurep 'server-sockets) (featurep 'datagram-sockets) would be a more generic approach. > > 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. > I agree that the combined functionality of open-network-stream is a large "black box". But why is that a problem? Maybe it isn't very pretty (it wasn't that before either), but it shares a fair amount of code and functionality between the various uses of the function. IMO, We should do what you suggest, but the other way round: We could rename the C-level function to, say, open-network-connection and write lisp-level wrappers (in simple.el) around it like open-network-stream, open-network-stream-nowait, open-network-stream-server, open-local-stream-nowait, open-local-stream, open-local-stream-server, open-datagram-server, open-datagram-client, etc. etc. Then you don't have 10 different C functions all doing variations of the same thing, but still the user will have all the `specific-purpose' functions handy. -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel