> > - we need to decide if Ryan's proposed fix to the mutex_child_init
should
> > stay or we stick with existing api. I've not been involved in it
heavily,
> > BUT can we have some votes as otherwise I'll stick with what we have.
>
> My preference is to wait on this. I think making such a drastic change
> *right* before we go to 1.0 is asking for trouble.
If we're happy that the API we have is fine, then we don't need a change.
There seems to be a feeling it's not.
Your strawman patch and Ryan's seem to be the 2 solutions proposed. We need
to move this forward.
> > - namespace protection in headers. Where do we stand on this? apr.hnw is
> > listed in STATUS?
>
> Realistically, I consider this a *yawn*. We could fix this up later, I
think.
Agreed
> > - thread return types. I see 2 +1's already for changing the type to an
> > apr_status_t. Anyone else care to comment/vote?
>
> I thought it wasn't portable to return a thread exit value on all OSes.
But,
> sure, I guess it sounds reasonable. +1.
Again we need to decide if we're gonna do this as it'll be a change to the
API.
> > - version to apr_initialise. I see enough 3 +1's, but a -1 and a -0, so
> > comments?
>
> I think it's a good idea, but Greg with his -1 (veto) needs to chime in.
Greg?
> > - apr_md5 functions. Should they change to void? Move to apr-util?
>
> MD5 already moved to apr-util. But, the return type is still
apr_status_t.
> Yet, I don't see a particularly compelling reason to change this to void.
Just seems a little pointless to return a status for functions that don't
have a success/fail.
david
|