From usocket-devel at common-lisp.net Wed Jan 3 22:41:31 2007 From: usocket-devel at common-lisp.net (usocket) Date: Wed, 03 Jan 2007 22:41:31 -0000 Subject: [usocket-ticket] Re: #7: Provide :external-format for stream and stream-server type sockets In-Reply-To: <080.919cdac204e6655695cb55c73bab234c@common-lisp.net> References: <080.919cdac204e6655695cb55c73bab234c@common-lisp.net> Message-ID: <089.ad794eef4aa9361a8b6960a0ee7067ee@common-lisp.net> #7: Provide :external-format for stream and stream-server type sockets --------------------------+------------------------------------------------- Reporter: ehuelsmann | Owner: default Type: enhancement | Status: new Priority: minor | Milestone: release-0.3 Component: tcp-socket | Version: Resolution: | Keywords: Patch: 0 | --------------------------+------------------------------------------------- Old description: > From one of my posts on the mailing list: > > "On IRC, I had some discussions whether it would be enough to just > support octet streams, but it looks like not all implementations > support octet streams. Definitely not all of them support > :external-format for sockets. > > So, as I mentioned in earlier posts, it might be a good idea to start > depending on flexi-streams: this gives us portable external-formats as > well as bivalent streams. The latter is important for many TCP/IP > protocols: HTTP has a character header, but binary content. Other > protocols have that too (8BIT smtp). > > So, to stay backward compatible, this is what I'd like to do: > > - If no external-format is given: just return the raw stream returned > by the implementation (as we do now) > > - If an external-format is specified, create a raw stream with 'octet' > element-type and wrap the returned stream with a flexi-stream, > exposing the flexi-stream to the caller." New description: From one of my posts on the mailing list: "On IRC, I had s ome discussions whether it would be enough to just support octet streams, but it looks like not all implementations support octet streams. Definitely not all of them support :external-format for sockets. So, as I mentioned in earlier posts, it might be a good idea to start depending on flexi-streams: this gives us portable external-formats as well as bivalent streams. The latter is important for many TCP/IP protocols: HTTP has a character header, but binary content. Other protocols have that too (8BIT smtp). So, to stay backward compatible, this is what I'd like to do: - If no external-format is given: just return the raw stream returned by the implementation (as we do now) - If an external-format is specified, create a raw stream with 'octet' element-type and wrap the returned stream with a flexi-stream, exposing the flexi-stream to the caller." Comment (by ehuelsmann): Some implementations (Franz, SBCL, Scieneer (?)) have bivalent streams natively, others don't support bivalent streams within their stream implementation. No implementations share the same spec for :external- format. In order for this issue to be resolved portably, there'd need to be a generic external-format specification which vendors adhere to. -- Ticket URL: usocket usocket From usocket-devel at common-lisp.net Wed Jan 3 22:42:30 2007 From: usocket-devel at common-lisp.net (usocket) Date: Wed, 03 Jan 2007 22:42:30 -0000 Subject: [usocket-ticket] Re: #7: Provide :external-format for stream and stream-server type sockets In-Reply-To: <080.919cdac204e6655695cb55c73bab234c@common-lisp.net> References: <080.919cdac204e6655695cb55c73bab234c@common-lisp.net> Message-ID: <089.a9ad3b34a917bdf55541612ea498ff49@common-lisp.net> #7: Provide :external-format for stream and stream-server type sockets --------------------------+------------------------------------------------- Reporter: ehuelsmann | Owner: default Type: enhancement | Status: new Priority: minor | Milestone: unassigned Component: tcp-socket | Version: Resolution: | Keywords: Patch: 0 | --------------------------+------------------------------------------------- Changes (by ehuelsmann): * milestone: release-0.3 => unassigned -- Ticket URL: usocket usocket From usocket-devel at common-lisp.net Sat Jan 20 00:25:30 2007 From: usocket-devel at common-lisp.net (usocket) Date: Sat, 20 Jan 2007 00:25:30 -0000 Subject: [usocket-ticket] Re: #1: Create API for connection-accepting stream sockets In-Reply-To: <080.fb52c8bea9dcf22af82801bf311fbbac@common-lisp.net> References: <080.fb52c8bea9dcf22af82801bf311fbbac@common-lisp.net> Message-ID: <089.150af4f3313c0fbda57f6bc39d0f257b@common-lisp.net> #1: Create API for connection-accepting stream sockets -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: task | Status: assigned Priority: blocker | Milestone: release-0.3 Component: tcp-socket | Version: Resolution: | Keywords: Patch: 1 | -------------------------+-------------------------------------------------- Changes (by ehuelsmann): * status: new => assigned Comment: Having started, I accept. -- Ticket URL: usocket usocket From usocket-devel at common-lisp.net Sat Jan 20 00:26:09 2007 From: usocket-devel at common-lisp.net (usocket) Date: Sat, 20 Jan 2007 00:26:09 -0000 Subject: [usocket-ticket] Re: #1: Create API for connection-accepting stream sockets In-Reply-To: <080.fb52c8bea9dcf22af82801bf311fbbac@common-lisp.net> References: <080.fb52c8bea9dcf22af82801bf311fbbac@common-lisp.net> Message-ID: <089.eb76fa3d8948329f9a6f1bd0d25a3a8f@common-lisp.net> #1: Create API for connection-accepting stream sockets -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: ehuelsmann Type: task | Status: closed Priority: blocker | Milestone: release-0.3 Component: tcp-socket | Version: Resolution: fixed | Keywords: Patch: 1 | -------------------------+-------------------------------------------------- Changes (by ehuelsmann): * resolution: => fixed * status: assigned => closed Comment: All 9 backends now implement socket-listen and socket-accept! yay! -- Ticket URL: usocket usocket From usocket-devel at common-lisp.net Sat Jan 20 11:33:34 2007 From: usocket-devel at common-lisp.net (usocket) Date: Sat, 20 Jan 2007 11:33:34 -0000 Subject: [usocket-ticket] Re: #2: Create/extend API to get/set socket options In-Reply-To: <080.b2b92285a4d69c1f3a056e3a2a762625@common-lisp.net> References: <080.b2b92285a4d69c1f3a056e3a2a762625@common-lisp.net> Message-ID: <089.4b43c60d0f15c1c250506ad0043d35a3@common-lisp.net> #2: Create/extend API to get/set socket options -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: default Type: task | Status: new Priority: blocker | Milestone: release-0.4 Component: tcp-socket | Version: Resolution: | Keywords: Patch: 0 | -------------------------+-------------------------------------------------- Changes (by ehuelsmann): * milestone: release-0.3 => release-0.4 Comment: The most important part of this api (REUSE_ADDRESS) has been implemented as an argument to SOCKET-LISTEN. It would be too bad if server-sockets would be released only after this API is implemented, especially since trivial-sockets doesn't offer anything similar either. Putting it this way, I guess '''this''' release doesn't block on exactly this API. -- Ticket URL: usocket usocket From usocket-devel at common-lisp.net Sat Jan 20 13:50:08 2007 From: usocket-devel at common-lisp.net (usocket) Date: Sat, 20 Jan 2007 13:50:08 -0000 Subject: [usocket-ticket] #8: socket-accept should support a timeout value Message-ID: <080.39d8ecd5805c9b54f4a37aa1ed016075@common-lisp.net> #8: socket-accept should support a timeout value -------------------------+-------------------------------------------------- Reporter: ehuelsmann | Owner: default Type: enhancement | Status: new Priority: minor | Milestone: unassigned Component: tcp-socket | Version: Keywords: useability | Patch: 0 -------------------------+-------------------------------------------------- The only way for systems to accept a connection is to block indefinitely waiting for one (which is highly impractical and influences the useability of the library) -- Ticket URL: usocket usocket