david reid wrote:
I think that somehow people aren't really "on the same page" as I am, so
I'll try and explain again what I'm aiming for. When fully implemented
the IO abstraction will allow ANY app to create it's own type of
apr_io_t - which can then be mised/matched with any other type of
apr_io_t within the app. In my imagination the revised apr_ssl code
simply creates apr_io_t's - there is no longer a notion of
files/sockets/pipes or anything else. All the code currently under
network_io and file_io goes away - replaced instead by code unser simply
'io'. The api is extensible - deliberatly so.
Now,if people don't want this or don't see a need then I'm happy to walk
away and forget it.
Can I offer a thought? Maybe a unified apr_io_read/write and the assoicated
entry points are the way to go... if we implement in terms of today's code,
and roll this out before 2.0, I suspect we will discover if folks are very
friendly to the unified API, or if they demand explicit methods against the
specific objects they are working with?
Bill
