[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New patch for server sockets and datagram (UDP) support.
From: |
Kim F. Storm |
Subject: |
Re: New patch for server sockets and datagram (UDP) support. |
Date: |
07 Mar 2002 13:39:50 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 |
Alex Schroeder <address@hidden> writes:
> 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).
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 <address@hidden> http://www.cua.dk
- Re: Non-blocking open-network-stream, Juanma Barranquero, 2002/03/01
- Re: Non-blocking open-network-stream, Richard Stallman, 2002/03/01
- New patch for server sockets and datagram (UDP) support., Kim F. Storm, 2002/03/06
- Re: New patch for server sockets and datagram (UDP) support., Kim F. Storm, 2002/03/07
- Re: New patch for server sockets and datagram (UDP) support., Alex Schroeder, 2002/03/07
- Re: New patch for server sockets and datagram (UDP) support.,
Kim F. Storm <=
- Re: New patch for server sockets and datagram (UDP) support., Alex Schroeder, 2002/03/07
- Re: New patch for server sockets and datagram (UDP) support., Richard Stallman, 2002/03/08
- Re: New patch for server sockets and datagram (UDP) support., Kim F. Storm, 2002/03/13
- Final(?) patch for server sockets and datagram (UDP) support., Kim F. Storm, 2002/03/13
- Re: Final(?) patch for server sockets and datagram (UDP) support., Al Petrofsky, 2002/03/13
- Re: Final(?) patch for server sockets and datagram (UDP) support., Kim F. Storm, 2002/03/14
- Re: Final(?) patch for server sockets and datagram (UDP) support., Richard Stallman, 2002/03/14
- Re: Final(?) patch for server sockets and datagram (UDP) support., Kim F. Storm, 2002/03/14
- I have installed the patch for server sockets and datagram (UDP) support., Kim F. Storm, 2002/03/17
- Re: New patch for server sockets and datagram (UDP) support., Helmut Eller, 2002/03/07