[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sockets Layer Counter Proposal
On Sun, 07 Oct 2012 16:22:38 -0400, Arthur A. Gleckler
On Sun, Oct 7, 2012 at 12:27 PM, Aaron W. Hsu <arcfide@xxxxxxxxxxx>
I suggest that they be merged simply because I don't think the
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
= Constructors and Predicates =
SRFI 106 Defines:
My sockets library defines:
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:
My library defines:
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 =
My library defines:
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 ==
== Additional Datatype constructors, predicates, and accessors ==
== Additional Procedures ==
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 | arcfide@xxxxxxxxxxx | http://www.sacrideo.us
Programming is just another word for the Lost Art of Thinking.