apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: apr_app_initialize???
Date Wed, 27 Nov 2002 17:23:14 GMT
At 12:08 AM 11/27/2002, rbb@apache.org wrote:

>Can anybody explain what this function is for?
>
>As near as I can tell, it converts argv from unicode to utf-8.  It can
>also do the same for the environment table.  I don't understand why this
>is necessary.  If we are dealing with the command line, then we expect the
>user to use apr_getopt, so can't we just do the conversion in that
>function?

That's a *really* interesting suggestion.  It would actually solve another issue
I'm confronting.

The problem with apr_getopt is that function *does not* demand the args
come from argv.  They can come from any string array.  So making this
change would, in reality, break all the other places this occurs.

The bottom line reason we plugged in apr_app_initialize is that on some
platforms, initializing a binary is very different from initializing a library.
If you have a plugable module somewhere, built on apr (think in terms of
an Apache 1.3 module compiled against APR), the behavior can be
somewhat different in what and how we initalize things.

And the last reason I offered up apr_app_initialize is to finally make APR
based services totally transparent to the app.  One thing that happens in
any service is that we have a non-standard shutdown notification API.
Another thing is that the argv[] passed to the application isn't the argv[]
that is passed to the StartService API function.  It's the hardcoded args
that are part of the ImagePath command line.

My goal [guess I need to focus on it and get it wrapped up] is to have
any app call apr_app_initialize, and for apr_app_initialize to recognize
that this app is being run as-a-service, and deal with all of the apr_event
stuff transparently to the app.

>As for the environment table, why don't we do that in apr_initialize?  It
>looks like we are requiring developers to use _our_ environment table if
>it is going to be portable.  I had never realized that before, and I
>_really_ dislike it.

apr_app_initialize corrects environ[] which is a standard ANSI table.
If the user prefers the main(int argc, char **argv, char **env) API, their
apr_app_initialize should match.  We are flexible here.

>This all came up because I found testapp.c, which doesn't test anything.
>I am trying to write a valid test for apr_app_initialize, but there aren't
>enough docs about what it is supposed to do.

That's because testapp.c was an example empty stub, with a microsoft
project file, that anyone could use to get started.

I guess it doesn't belong in test/ at all, but perhaps in an example/ tree.

Bill


Mime
View raw message