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?
Brad >>> On 6/28/2006 at 1:18 PM, in message <[EMAIL PROTECTED]>, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > david reid wrote: >> Justin Erenkrantz wrote: >>> On 6/28/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >>>> The only problem I have with an apr_write, is that it's way to easy >>>> 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 it. > > 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 think >> 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 the > performance of explicit methods would not be impacted. If someone runs > 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 a > 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, and > still > offer explicit methods. Please correct me if I'm lost. > > Bil
