You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@opengroup.org> on 1997/07/21 15:46:35 UTC

Re: after you finish shooting me...

Dean Gaudet <dg...@arctic.org> wrote:

> Well if we do it now then we get to hear module authors scream about 5
> betas from now when they start trying 1.3.  In or around when one of the
> other Great Schemes gets done is an ok time too... but there's no way I'm
> generating a patch for this, it'll be huge and there's no way I want to do
> it twice.  I want permission beforehand to stick static in front of
> hundreds of functions.

Can we scream now?  I don't think it's a good idea to static-ize
until/unless clean "public" API access is given to certain pieces you
plan to make private.  To give you an idea of how much my head would
hurt: 

The DCE stuff needs to get at lots of stuff I imagine you'd like to
make static, some bits from STANDALONE_MAIN:

void
wand_main(int ac, char *av[])
{
    ...
    standalone = 1;

    chdir(server_root);

    clear_pool (pconf);
    ptrans = make_sub_pool (pconf);

    server_conf = read_config (pconf, ptrans, server_confname); 
    init_modules (pconf, server_conf);
    open_logs (server_conf, pconf);

    default_server_hostnames (server_conf);

    set_signals ();
    log_pid (pconf, pid_fname);

    ...
}
 
The RPC routine that is somewhat equivalent to child_main:

dcewand_common(...)
{
    ...
    BUFF *conn_io;
    request_rec *r;
    conn_rec *current_conn;
    struct sockaddr sa_server, sa_client;
    ...

    conn_io = bcreate(apache_ptrans, B_RDWR);
    conn_io->t_handle = (void*)ch;

    (void)sfdisc(conn_io->sf_in, SF_POPDISC);
    sfdisc(conn_io->sf_in, sfwand_new(conn_io->pool, conn_io, ch));
    sfsetbuf(conn_io->sf_in, NULL, 0);

    (void)sfdisc(conn_io->sf_out, SF_POPDISC);
    sfdisc(conn_io->sf_out, sfwand_new(conn_io->pool, conn_io, ch));
    sfsetbuf(conn_io->sf_out, NULL, 0);

    current_conn = new_connection (ptrans, server_conf, conn_io,
				   (struct sockaddr_in *)&sa_client,
				   (struct sockaddr_in *)&sa_server,
				   child_num);

    r = read_request(current_conn);
    process_request(r);

    ...
}

The rdacl interface needs to run translate_name() when the DCE client
sec_acl API is invoked by a non-HTTP client (e.g. dcecp):
...
      r = (request_rec *)fake_apache_request(canon);
      translate_name(r);  
      if(stat(r->filename, &Sb)) {
      ...
      fake_apache_request_end(r); 

Some Perl stuff:
mod_perl:config.c

#ifdef PERL_SECTIONS /* <Perl></Perl> */
/* some prototypes for -Wall sake */
const char *handle_command (cmd_parms *parms, void *config, const char *l);
const char *limit (cmd_parms *cmd, void *dummy, const char *arg);
void add_per_dir_conf (server_rec *s, void *dir_config);
void add_per_url_conf (server_rec *s, void *url_config);
void add_file_conf (core_dir_config *conf, void *url_config);
const command_rec *find_command_in_modules (const char *cmd_name, module **mod);

There's other areas where the DCE and Perl plugins would suffer from
such changes, please, think this over again.  Can it wait for 2.0?

-Doug



Re: after you finish shooting me...

Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 21 Jul 1997, Doug MacEachern wrote:

> Dean Gaudet <dg...@arctic.org> wrote:
> 
> > Well if we do it now then we get to hear module authors scream about 5
> > betas from now when they start trying 1.3.  In or around when one of the
> > other Great Schemes gets done is an ok time too... but there's no way I'm
> > generating a patch for this, it'll be huge and there's no way I want to do
> > it twice.  I want permission beforehand to stick static in front of
> > hundreds of functions.
> 
> Can we scream now?  I don't think it's a good idea to static-ize
> until/unless clean "public" API access is given to certain pieces you
> plan to make private.  To give you an idea of how much my head would
> hurt:

Well at a minimum I want to staticize the modules.  Some of them cloud the
global namespace in ways that scare me.

BTW, mod_perl would be justified in defining CORE_PRIVATE and getting
those definitions from http_core.h... we just need to add them to
http_core.h.

I'd be happy trying to figure out what of that other stuff needs to be
prototyped.  How about you mail me your list of prototypes and lemme see
if I can figure out something clean?

> const char *limit (cmd_parms *cmd, void *dummy, const char *arg); 

I changed this to limit_section to avoid various local-shadows-global
warnings. 

Dean