Re: New patch for server sockets and datagram (UDP) support.

[Kim F. Storm]

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