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 15:51:37 +0100 Message-ID: <87it88bfd2.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> <874rjsd2uc.fsf@gnu.org> <5xbse0pn55.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 1015513139 15059 195.204.10.66 (7 Mar 2002 14:58:59 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 7 Mar 2002 14:58:59 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 16izMA-0003un-00 for ; Thu, 07 Mar 2002 15:58:59 +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 16izEb-00021h-00; Thu, 07 Mar 2002 09:51:09 -0500 Original-Received: from relay02.cablecom.net ([62.2.33.102]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16izDf-0001zK-00 for ; Thu, 07 Mar 2002 09:50:11 -0500 Original-Received: from mail.swissonline.ch (mail.swissonline.ch [62.2.32.83]) by relay02.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id g27Eo9E98303; Thu, 7 Mar 2002 15:50:09 +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 g27Eo9227675; Thu, 7 Mar 2002 15:50:09 +0100 (MET) Original-Received: from alex by confusibombus with local (Exim 3.12 #1 (Debian)) id 16izF3-0000Ef-00; Thu, 07 Mar 2002 15:51:37 +0100 Original-To: storm@cua.dk (Kim F. Storm) 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: <5xbse0pn55.fsf@kfs2.cua.dk> (storm@cua.dk's message of "07 Mar 2002 13:39:50 +0100") Original-Lines: 49 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:1782 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1782 storm@cua.dk (Kim F. Storm) writes: > 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... Haha, that was a cheap trick, then. :) Anyway, if you provide a list of special purpose functions as discussed at the end, then this is a non-issue anyway. Thanks. >> 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). Thanks for considering this. > Alternatively, using something like > (featurep 'server-sockets) > (featurep 'datagram-sockets) > would be a more generic approach. That would be nice, or combined with the functions you mention next, this seems good. > 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. That sounds ok to me because I only care about the Lisp level. Other people shall judge maintenace issues or code issues on the C level. Thanks, Kim. Alex. -- http://www.emacswiki.org/ _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel