On Sun, 2005-02-13 at 16:28 +1100, Bojan Smojver wrote:
I'm not sure why constructing a request would be so unusual. Application
servers running inside Apache may need to do this stuff all the time.
Just a little clarification here. The text here:
Quoting Bojan Smojver [EMAIL PROTECTED]:
If canned sub-request functions are used, custom
sub-request functionality is difficult to achieve without not so nice
workarounds.
The above comment is in relation to server/request.c file and functions defined
there. There is a static function
. And if it is referring to one of those functions via defining
CORE_PRIVATE, then it rightly deserves a thrashing.
OK, maybe. But there are plenty of other modules inside Apache distro
itself that use CORE_PRIVATE stuff too. This comes to my original
question - what is really considered public API
On Fri, Feb 11, 2005 at 03:00:15PM +1100, Bojan Smojver wrote:
...
For example, function ap_create_request_config() is required in order to
create
request_config for every new request. It knows about some internal sizes and
the like. It is under CORE_PRIVATE, so any module that needs to
where if you are GPL you gain access to more of the kernel
then if you are not. There are no legal ramifications of using the
CORE_PRIVATE as I use it quite a bit in my mod_ftpd module on
outoforder.cc
these functions and structures. It isn't like the Linux kernel's
MODULE_LICENSE where if you are GPL you gain access to more of the kernel
then if you are not. There are no legal ramifications of using the
CORE_PRIVATE as I use it quite a bit in my mod_ftpd module on
outoforder.cc
I see now that I
Bojan Smojver wrote:
if I rely on what's below CORE_PRIVATE, am I setting myself up
for a disaster when those things change without notice?
I think the answer to this is similar to the old line if you need to ask
how much it costs you can't afford it.
;)
--Geoff
On Fri, Feb 11, 2005 at 06:26:00AM +1100, Bojan Smojver wrote:
...
When I said legal, I meant that in the technical sense. Along the
lines of if I rely on what's below CORE_PRIVATE, am I setting myself up
for a disaster when those things change without notice?
Basically, are functions and
Greg Stein wrote:
On Fri, Feb 11, 2005 at 06:26:00AM +1100, Bojan Smojver wrote:
...
When I said legal, I meant that in the technical sense. Along the
lines of if I rely on what's below CORE_PRIVATE, am I setting myself up
for a disaster when those things change without notice?
Basically, are
--On Thursday, February 10, 2005 4:57 PM -0800 Paul Querna
[EMAIL PROTECTED] wrote:
So, there is no guaranteed binary compat for any module that defines
CORE_PRIVATE?
I would think that any module that #define's CORE_PRIVATE is on its own and
righly so. -- justin
Quoting Greg Stein [EMAIL PROTECTED]:
If you *do* need something hidden by CORE_PRIVATE, then bring it up along
with a rationale for why that thing should be made public. That's your
best solution.
Get it.
For example, function ap_create_request_config() is required in order to create
Quoting Bojan Smojver [EMAIL PROTECTED]:
I'm trying to rely on functions that help in creating sub-requests,
Actually, that would be requests as well, not just sub-requests.
--
Bojan
I'm trying to understand the meaning of this #define a bit better. It appears in
publicly available header files (by that I mean installed in a system wide
location) and it basically allows access to otherwise invisible things inside
Apache. Several modules in the Apache distribution are defining
13 matches
Mail list logo
