On Sun, 07 Oct 2012 16:22:38 -0400, Arthur A. Gleckler
<xxxxxx@speechcode.com> wrote:

> On Sun, Oct 7, 2012 at 12:27 PM, Aaron W. Hsu <xxxxxx@sacrideo.us>
> wrote:
>
>> I suggest that they be merged simply because I don't think the
>> differences
>> are 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/unless

Full 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 | xxxxxx@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the Lost Art of Thinking.