[usocket-cvs] r4 - usocket/trunk/doc

[ehuelsmann at common-lisp.net]

Author: ehuelsmann
Date: Sat Jan 28 16:52:58 2006
New Revision: 4

Modified:
   usocket/trunk/doc/design.txt   (contents, props changed)
Log:
Update design document.

Modified: usocket/trunk/doc/design.txt
==============================================================================
--- usocket/trunk/doc/design.txt	(original)
+++ usocket/trunk/doc/design.txt	Sat Jan 28 16:52:58 2006
@@ -1,19 +1,72 @@
 
                                                         -*- text -*-
 
+$Id$
+
+
                   usocket: Universal sockets library
                   ==================================
 
 Contents
 ========
 
+ * Motivation
+ * Design goal
+ * Functional requirements
+
+
+
+

+Motivation
+==========
+
+There are 2 other portability sockets packages [that I know of]
+out there:
 
+ 1) trivial-sockets
+ 2) acl-compat (which is a *lot* broader, but contains sockets too)
 
+The first misses some functionality which is fundamental when
+the requirements stop being 'trivial', such as finding out the
+addresses of either side connected to the tcp/ip stream.
+
+The second, being a complete compatibility library for Allegro,
+contains much more than only sockets.  Next to that, as the docs
+say, is it mainly directed at providing the functionality required
+to port portable-allegroserve - meaning it may be (very) incomplete
+on some platforms.
+
+So, that's why I decided to inherit Erik Enge's project to build
+a library with the intention to provide portability code in only
+1 area of programming, targeted at 'not so trivial' programming.
+
+Also, I need this library to extend cl-irc with full DCC functionality.
+
+

 Design goal
 ===========
 
-To provide a portable socket interface for as many implementations as
-possible, while keeping the portability layer as thin as possible.
+To provide a portable TCP/IP socket interface for as many
+implementations as possible, while keeping the portability layer
+as thin as possible.
+
+
+

+Functional requirements
+=======================
+
+The interface provided should allow:
+ - 'client'/active sockets
+ - 'server'/listening sockets
+ - retrieve IP addresses/ports for both sides of the connection
+ - provide the usual stream methods to operate on the connection stream
+   (not necessarily the socket itself; maybe a socket slot too)
+
+Several relevant support functionalities will have to be provided too:
+ - long <-> quad-vector operators
+ - quad-vector <-> string operators
+ - hostname <-> quad-vector operators (hostname resolution)
+
 
 Minimally, I'd like to support:
  - SBCL