This page is part of the web mail archives of SRFI 106 from before July 7th, 2015. The new archives for SRFI 106 contain all messages, not just those from before July 7th, 2015.
On Sun, Oct 7, 2012 at 12:27 PM, Aaron W. Hsu <arcfide@xxxxxxxxxxx> wrote:I suggest that they be merged simply because I don't think the differencesare very great, and I think having two SRFIs for this would only make things more confusing.Would you mind summarizing the differences?
Sure, I can try. I'll try to follow the general pattern of the SRFI document. I will begin with the relative equivalencies between the interfaces.
= Constructors and Predicates = SRFI 106 Defines: make-client-socket make-server-socket socket? My sockets library defines: create-socket socket? Differences:Most notably, the make-client-socket and make-server-socket and the create-socket interfaces are different. The make-client-socket and make-server-socket procedures are somewhat tied to assumptions about the types of sockets that are being created, namely, INET sockets. The interface seems to restrict the socket creation to only TCP or UDP sockets, without any hope of scaling up to anything else without creating a whole new interface.
The create-socket procedure only accepts the domain, type, and protocol, which are optional flags in SRFI 106. It does not presume that the address is an INET address, and does not assume a specific listening or binding address for the server socket, which SRFI 106 does right now. Listening on a socket and binding a socket for service is done explicitly via the bind-socket and connect-socket procedures. Note that it is not necessary to make an explicit connection on a socket, but SRFI 106 does not permit one to have an unconnected socket.
= Socket Operations = SRFI 106 Defines: socket-accept socket-send socket-recv socket-shutdown socket-close My library defines: bind-socket connect-socket listen-socket accept-socket close-socket shutdown-socket send-to-socket receive-from-socket Differences:bind-socket and connect-socket behavior are merged into the behavior of socket creation in SRFI 106 right now. This functionality is separate in my library. There is no listen-socket equivalent in SRFI 106. SRFI 106's version of accept-socket returns only a socket, while my version returns a socket and an address object. In my version of sendto, the user specifies an address as well as the buffer of data to send.
= Port Conversion =I provide a separate library for converting sockets to ports, as sockets cannot always be conveniently or even safely converted to ports or back.
= Control feature =I do not have a call-with-socket as the specification as given does not seem to be useful. It does not do anything except call socket with proc, which can be done by saying (proc socket).
= Constants = SRFI-106 Defines: AF_UNSPEC AF_INET AF_INET6 SOCK_STREAM SOCK_DGRAM AI_PASSIVE AI_CANONNAME AI_NUMERICHOST AI_V4MAPPED AI_ALL AI_ADDRCONFIG SHUT_RD SHUT_WR SHUT_RDWR My library defines: address-info/canonical-name address-info/numeric-host address-info/passive socket-domain/unix socket-domain/local socket-domain/stream socket-domain/datagram socket-type/sequence-packet socket-type/raw socket-type/random socket-protocol/auto shutdown-method/read shutdown-method/write shutdown-method/read&write send-to/dont-route send-to/out-of-band receive-from/out-of-band receive-from/peek receive-from/wait-all receive-from/dont-wait Differences:I am unsure about the definitions in SRFI 106, but my library expects these constants to be defined as opaque objects exported from the library itself. These constants are not expected to be inspected or broken apart in any way, and should/must for all intents and purposes
appear as a single atom. = Additional elements without equivalents in SRFI 106 = In addition to the above, I also provide the following. == Accessors for Sockets == socket-fd socket-domain socket-type socket-protocol == Additional Datatype constructors, predicates, and accessors == socket-option? make-socket-option define-socket-option-type make-tcp-option make-udp-option make-raw-option make-ip-option tcp-option? udp-option? raw-option? ip-option? socket-address? unix-address? make-unix-address unix-address-path internet-address? make-internet-address internet-address-ip internet-address-port make-address-info address-info address-info-domain address-info-type address-info-protocol address-info-address make-socket-domain make-socket-type make-socket-protocol socket-protocol? protocol-entry-name protocol-entry-aliases protocol-entry-value shutdown-method? make-shutdown-method make-send-to-option make-receive-from-option make-socket-condition socket-condition? socket-condition-who socket-condition-syscall socket-condition-type socket-condition-message == Additional Procedures == get-address-info internet-address->string string->internet-address string->ipv4 register-socket-domain! next-protocol-entry get-protocol-by-name get-protocol-by-constant open-protocol-database close-protocol-database socket-maximum-connections get-socket-option set-socket-option! set-socket-nonblocking! socket-nonblocking? socket-error socket-raise/unlessFull documentation of these features is available in the indexed PDF on my website. However, it does address a few things that are currently listed as issues in the SRFI. Firstly, it take sthe view of creating schemely names for the POSIX equivalents. Secondly, it makes less critical the question about how many variables the SRFI need support. Socket options, domains, types, protocols, and socket addresses are all given the portable subset of their kinds (unix/local domains are an exception, but the library provides for the reporting of unsupported features), but the user can, at the user level, without requiring implementation support or additional implementation work, utilize additional variables and features by creating new socket options or the like which correspond to the system equivalents that they care about. This allows for code that makes use of implementation specific behavior to run on multiple scheme implementations that support the library without requiring explicit support for those extensions by the implementation: it is enough to implement the library alone. The interface is designed to be lightweight, relatively simple, and yet still scale to any number of extensions in an user extensible way.
Currently, most socket proposals do not do this. They provide only TCP and UDP (sometimes Local), without ever making it possible to scale beyond those things. My library provides ready TCP and UDP out of the box, but makes possible extending it. Moreover, the interface supports a number of patterns of usage that are not supported by the current SRFI proposal or many other interfaces. This includes, for example, the ability to have an unbound socket, or an unconnected socket.
-- Aaron W. Hsu | arcfide@xxxxxxxxxxx | http://www.sacrideo.us Programming is just another word for the Lost Art of Thinking.