apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elrond <elr...@samba-tng.org>
Subject Re: [RFC] Network Abstraction Layer
Date Fri, 02 Mar 2001 20:34:33 GMT
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

Mime
View raw message