apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <bnicho...@novell.com>
Subject Re: io abstractions
Date Wed, 28 Jun 2006 21:01:46 GMT
  Forgive me for jumping in late and I have to admit that I haven't
looked at the API's yet, but why do we need a new API?  Shouldn't the
apr_socket abstraction carry enough information so that apr_write()
would be sufficient and do the right thing?


>>> On 6/28/2006 at 1:18 PM, in message
<44A2D61F.5030704@rowe-clan.net>, "William
A. Rowe, Jr." <wrowe@rowe-clan.net> wrote:
> david reid wrote:
>> Justin Erenkrantz wrote:
>>> On 6/28/06, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>>>> The only problem I have with an apr_write, is that it's way to
>>>> to mis-use
>>>> apr_write when you ment to use apr_ssl_write explicitly, or 
>>>> apr_registry_write,
>>>> or any thousands of other applications.
>> Hmm, either I haven't explained myself properly or you don't get
> Apparently not, did the page jump under me?
>>>> _write, _read are methods, so they should be decorated with an 
>>>> object.  Typing
>>>> _io really doesn't take that long for the coder using our iol 
>>>> abstration, no?
>> BTW, please stop referring to it as iol abstraction - it's not iol -

>> it's plain old io. iol implies other aspects for me and while I
>> they're cool they'd live on top of this layer.
> Ok, when I totally +1'ed all of this new functionality, I begged that
> performance of explicit methods would not be impacted.  If someone
> solely
> with a socket, there is no reason to add the overhead of
abstractions.  If 
> it's
> a file, I don't want the code looking to see if it aught to deal with
> console.
> (Ok, sorta bad example, since there is no difference on unix.)
> I'm hoping we are on the same page that we have an abstration layer,
> still
> offer explicit methods.  Please correct me if I'm lost.
> Bil

View raw message