From dev-return-1600-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Mar 02 20:35:59 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 6182 invoked by uid 500); 2 Mar 2001 20:35:11 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 6064 invoked from network); 2 Mar 2001 20:34:39 -0000 Date: Fri, 2 Mar 2001 21:34:33 +0100 From: Elrond To: Luke Kenneth Casson Leighton , Sander Striker , dev@apr.apache.org Subject: Re: [RFC] Network Abstraction Layer Message-ID: <20010302213433.A18378@baerbel.mug.maschinenbau.tu-darmstadt.de> Mail-Followup-To: Elrond , Luke Kenneth Casson Leighton , Sander Striker , dev@apr.apache.org References: <20010301201709.A20432@baerbel.mug.maschinenbau.tu-darmstadt.de> <20010302021704.W2297@lyra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010302021704.W2297@lyra.org>; from gstein@lyra.org on Fri, Mar 02, 2001 at 02:17:05AM -0800 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, Mar 02, 2001 at 02:17:05AM -0800, Greg Stein wrote: [...] > My personal, uninformed opinion :-) would tend towards adding new > OS-provided socket types to apr_socket_t (allowing all apps the benefit of > the new socket types; not just those that can fill in a func table), and [...] That gave me a good hint. I investigate apr_socket_t closely. I like the _external_ API! It's realy quite good. It fits quite exactly, what we need. What I don't like is the "internal" way, because it doesn't allow an application/library to add apr_socket_ts at runtime. I would like something like in the buckets area: Having some apr_socket_type_t with function pointers and the like. apr_send() will then mostly only call the appropiate function pointers and the old "hardcoded" apr_send() will be that fn-ptr. Most of this is quite straightforward to implement and it wont even break any applications (Apache!?), that already depend on the current API, because most is only internal rewriting and exposing some things. The thing, that asks for some proper design is apr_pollfd_t related stuff: sockets might have a filedescriptor, that the base poll()/select() can use, but they might find out, that there actualy is no data, that they could hand over to the application. In the worst case, there might exist sockets, that can't even provide with a nice filedescriptor, some *arg* polling or other good means would be needed. This requires a good thought out API in the apr_socket_type_t-fn-struct. BTW: apr already has some "own" sockets: one can convert an apr_file_t into a socket... I doubt apr_setsockopt (or what it is named) does any good on it... Having a proper apr_socket_type_t apr_file_socket_type_t would help here. Elrond