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: Non-blocking open-network-stream Date: 03 Mar 2002 01:12:08 +0100 Message-ID: <5xr8n2o6g7.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> <200203020759.IAA18231@xaital.online-marketwatch.com> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: quimby2.netfonds.no 1015114664 4779 195.204.10.66 (3 Mar 2002 00:17:44 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 3 Mar 2002 00:17:44 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 16hJh9-0001Ey-00 for ; Sun, 03 Mar 2002 01:17:44 +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 16hJbf-0005r5-00; Sat, 02 Mar 2002 19:12:03 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.33 #1 (Debian)) id 16hJak-0005oA-00 for ; Sat, 02 Mar 2002 19:11:06 -0500 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 4B9547C047; Sun, 3 Mar 2002 00:11:04 +0000 (GMT) Original-To: Helmut Eller In-Reply-To: <200203020759.IAA18231@xaital.online-marketwatch.com> Original-Lines: 76 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:1696 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1696 Helmut Eller writes: > storm@cua.dk (Kim F. Storm) writes: > > > (do we have papers for that?) > > No. If needed, I will sign papers. > > > However, I think it can be done via open-network-stream: > > > > If the HOST argument is nil, a server socket is opened which > > accepts connections. The sentinel is called - with a newly > > created process - whenever a connections is accepted. > > I see several problems with this approach: > > - What is the process-name for the connections? The same as for the > server socket? All connections with the same name? My idea is to name it as the server process concatenated with the ip address and source port of the client, i.e. something like "service <10.20.30.40:3248>" I prefer this to manually having to give each connection a unique name in advance (as would be necessary with your accept-connection API). > > - How do you open a Unix server socket? > I intent do rename the NON-BLOCKING argument to a more generic TYPE argument. Eventually, it could be things like: If HOST specified - connect to that host: nil - blocking connect (tcp) to SERVICE on HOST t - non-blocking connect (tcp) to SERVICE on HOST udp - open udp socket with target SERVICE on HOST unix - connect to unix socket on address SERVICE If HOST is nil - open a server socket: nil - open tcp socket listning on SERVICE port t - same as nil udp - open udp socket bound to SERVICE port unix - open unix socket bound to address SERVICE > - It's possible to open Unix server sockets. It would be reasonable > to support Unix client sockets too. How can this be done? > See above. (IIRC, Your patch didn't cover unix sockets) > - What should NON-BLOCKING mean for server sockets? See above. > > - open-network-stream takes already 7 arguments. Putting even more > functionality in makes it hard to document. I don't agree. Renaming NON-BLOCKING to TYPE and switching on whether HOST is non-nil (connect) or nil (start server) seems fairly clean and simple to me. > > Server sockets are IMHO different enough to merit a separate > function. What is the advantage of merging those concepts? > Most of the necessary functionality is already in open-network-stream, so adding the server part there is pretty orthogonal I think. -- Kim F. Storm http://www.cua.dk _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel