Go ahead, and then someone can put static on every other function that
you're not using to stop you from using any more you're not supposed to be
:)
Dean
On Tue, 17 Mar 1998, Doug MacEachern wrote:
> I have a feeling I'm not going to get any +1's on this patch. I know it
> wouldn't be a warm, fuzzy +1 for anyone (including myself), but it doesn't
> break anything, just makes a few functions visible to the module dlls. <Perl>
> configuration under win32 would make lots of folks happy, and it's a big
> feature that none of the other win32 HTTP servers have to offer :-) Any
> strong objections to me committing this patch?
>
> -Doug
>
> Doug MacEachern wrote:
>
> > Dean Gaudet wrote:
> >
> > > srm_command_loop I'm definately FOR adding to the api, that's an
> > > oversight...
> > >
> > > But I'm confused, I thought that once we put in the pcfg stuff you
> > > wouldn't need things like limit_section() and init_virtual_host() and
> > > whatnot. Can't you just pcfg_open_custom/srm_command_loop for those?
> >
> > We have started using pcfg_open_custom for feeding strings to the config
> > gears, which works quite nice. But, the direct Perl variable -> config
> > mapping doesn't use pcfg_open_custom yet, and would require a considerable
> > amount of work to do so, including maintaining backwards compatibility w/
> > 1.2.x. In other words, the <Perl> stuff is currently stable, heaps of
> > people rely on it. Only a few API_EXPORTs and magic, the feature is
> > available to win32 users and presumably just as stable as it is under unix.
> > <Perl> sections under win32 could hook into the windows registry and other
> > funky stuff. Since some of these functions are clearly not part of the
> > "API", how about a
> >
> > #define CORE_EXPORT API_EXPORT
> >
> > or something like that, which does the same as API_EXPORT, but doesn't
> > advertise itself as "public" to readers of the source code?
> >
> > -Doug
>
>
>
>
|