Perrin Harkins wrote:
[...]
Let's step back for a minute. I am late to this party, since I haven't
been working on the mp2 code at all or even doing much with it. Here's
what it looks like to me, and please correct me if I'm wrong:
Because of the way the C API is laid out, it made sense to put
> Hmm, I now see why Apache::Server is not quite suitable for
> exists_config_define. As I've suggested in one of the replies re:
> current_callback. exists_config_define(@_) is not a server instance
> "attribute", but Apache's application "attribute". So if when we write
> Apache::Server we are t
Perrin Harkins wrote:
Stas Bekman wrote:
I don't have much to comment on these issues. I'm not going to repeat
again and again why the separation into multiple modules is important.
I don't think anyone would have a problem with the multiple files, if we
can just hide that unexpected complexit
Geoffrey Young wrote:
I don't think so. beneath it all each object method needs access to the c
request_rec, and $r needs to keep its singleton nature. which doesn't mean
you can't subclass it, you just need to use the bless { r => $r}, $class
syntax. that's what I meant by "the same way you ca
Stas Bekman wrote:
I don't have much to comment on these issues. I'm not going to repeat
again and again why the separation into multiple modules is important.
I don't think anyone would have a problem with the multiple files, if we
can just hide that unexpected complexity from end users.
It
[EMAIL PROTECTED] wrote:
geoff 2004/01/19 11:02:41
Modified:lib/Apache compat.pm
t/response/TestAPI server_util.pm
t/response/TestCompat apache.pm
xs/maps apache_functions.map
Log:
Apache::exists_config_define is now Apache::Server::exi
Geoffrey Young wrote:
I just couldn't keep up with the multiple threads under the old subject :)
but also what would have helped is not to reply to the same message, but start
a new one and copy the reply to it. You've changed the subject but mail
clients still file them under the original thread
Geoffrey Young wrote:
[...]
as for your earlier suggestions, I was waiting for stas to comment on them.
I don't have much to comment on these issues. I'm not going to repeat again
and again why the separation into multiple modules is important. It may be
unimportant to many users, but we aren't g
Geoffrey Young wrote:
The problem that bothers me is the pool. Since now we have
$s->server_root_relative, it's almost as bad as using a global pool if
users will happen to use it in requests, because it'll leak memory
untill the server is killed. And users will use it, just because they can.
wil
> Neither is loading a bunch of modules that you don't actually access
> directly,
well...
> or using a program to look up where the docs for the method
> you're calling are. There are basic expectations that programmers have
> about when they need to load things and where they can find docs, a
Geoffrey Young wrote:
In most languages, defining class A methods in class B would not even be
allowed, and I kind of wish it wasn't allowed in Perl either so we
wouldn't have to have this discussion.
good thing Perl isn't most languages ;)
There are some legitimate uses for this feature
> The problem that bothers me is the pool. Since now we have
> $s->server_root_relative, it's almost as bad as using a global pool if
> users will happen to use it in requests, because it'll leak memory
> untill the server is killed. And users will use it, just because they can.
will it really lea
I just couldn't keep up with the multiple threads under the old subject :)
>> my reading of method_register() is that it's global to all requests - it
>> doesn't make sense to define a new http method during a request. so,
>> move
>> that to Apache::Server::method_register() (defined in ServerUti
moving to a new thread, since there are multiple issues in the other one...
> In most languages, defining class A methods in class B would not even be
> allowed, and I kind of wish it wasn't allowed in Perl either so we
> wouldn't have to have this discussion.
good thing Perl isn't most languages
Geoffrey Young wrote:
If the example function is_initial_req() does not use a record of request_rec
and you think it makes no sense to define it in Apache::RequestRec then my
conclusion is it makes also no sense to do a $r->is_initial_req() for the
same reason and I'm happy to use Apache::Reque
Am Montag, 19. Januar 2004 15:03 schrieb Geoffrey Young:
> > If the example function is_initial_req() does not use a record of
> > request_rec and you think it makes no sense to define it in
> > Apache::RequestRec then my conclusion is it makes also no sense to do a
> > $r->is_initial_req() for the
> If the example function is_initial_req() does not use a record of request_rec
> and you think it makes no sense to define it in Apache::RequestRec then my
> conclusion is it makes also no sense to do a $r->is_initial_req() for the
> same reason and I'm happy to use Apache::RequestUtil::is_ini
Am Sonntag, 18. Januar 2004 07:14 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >>>
> >>>and im sure my next project start with this lines too. If someone ask
> >>> why my answer is I do not know, but it does not work otherwise.
> >>
> >>And that's fine. Think of mp2 as a bunch of CPAN module
18 matches
Mail list logo
