On Mon, Mar 31, 2008 at 11:15 AM, Roy T. Fielding [EMAIL PROTECTED] wrote:
Unfortunately, after last year's experience of being the only server
person around who wasn't working on a Joost release,
*hides*
I decided to delay
my arrival until Tuesday rather than attend the hackathon.
On Mon, Mar 31, 2008 at 7:41 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
I sympathize, but this doesn't reflect the addition of lua blocks...
those blocks can be trivially implemented as a loadable module ;-)
As I grok it, the point would be throw out our ridiculous config
syntax
On Mon, 31 Mar 2008 11:15:38 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
On Mar 31, 2008, at 10:39 AM, Paul Querna wrote:
Just read the mod_rewrite docs:
http://httpd.apache.org/docs/2.2/rewrite/rewrite_tech.html#InternalAPI
They are already exposing internals to users'.
Not, erm,
William A. Rowe, Jr. wrote:
-0.5 PLEASE not in the core. Make mod_wombat a standard module and
part of the default moduleset, whatever, but let's not make more core
dependencies, please?!?
-0.99 - agreed. Perl is perfectly happy having perl blocks as modular
behaviors... I've noticed a
On Tue 01 Apr 2008, Paul Querna wrote:
William A. Rowe, Jr. wrote:
-0.99 - agreed. Perl is perfectly happy having perl blocks as modular
behaviors... I've noticed a trend in the last few years of building on
the core (and folks rightfully accused me of growing mod_proxy core when
new
Torsten Foertsch wrote:
On Tue 01 Apr 2008, Paul Querna wrote:
William A. Rowe, Jr. wrote:
-0.99 - agreed. Perl is perfectly happy having perl blocks as modular
behaviors... I've noticed a trend in the last few years of building on
the core (and folks rightfully accused me of growing
Can we 1st determine exactly what pain-point we're trying to solve here?
Or, at least, prioritize them?
It seems to me that if the main issue is runtime re-configuration
during the request/response phases, then that really forces us into
something which must be very lean, mean and FAST. By
On 4/1/08 5:35 AM, Issac Goldstand [EMAIL PROTECTED] wrote:
I don't think we're even talking about on-the-fly stuff for the Lua
parser engine, so Perl can do everything that Lua can.
I am.
The biggest problems I have with current system are:
-Every module does things differently
-No real
On Apr 1, 2008, at 2:17 AM, Justin Erenkrantz wrote:
On Mon, Mar 31, 2008 at 7:41 PM, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
I sympathize, but this doesn't reflect the addition of lua
blocks...
those blocks can be trivially implemented as a loadable module ;-)
As I grok it, the
IMO, we work best when we feel empowered to scratch our itches...
As we've also seen, sometimes all it takes is someone to create
a rough framework of an implementation for people to get excited
by it and jump right on in, adding, extending and tuning it.
This reminds me: a serf BOF or session
On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
You cannot add virtual servers on the fly
Hmmm let's see now. If we have a default Vhost that all non-matched
name-based hosts get directed to configured, then a mod_perl based
handler can be adjusted to look at the Server header and do
On Mar 31, 2008, at 2:15 PM, Roy T. Fielding wrote:
Users like mod_rewrite for many reasons, but I think mostly because it
does so many things that almost every Apache hosting provider needs to
have it installed and usable in .htaccess
Except for web hosting companies, and some special
Akins, Brian wrote:
My opinion (which is worthless, I know) is to pick one way and do it. Lua
is easy to learn and satisfies most (all?) of our requirements. And if
Brian M. and I can learn it, anyone can ;)
The trouble is, if I want to solve problem A (configure the server),
and I find
Let me try and summarize this then:
Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
Where they can configure things on a request basis and add vhosts and
such without restarting httpd.
Solutions propose:
- lua in
On Apr 1, 2008, at 9:34 AM, Graham Leggett wrote:
Jim Jagielski wrote:
This reminds me: a serf BOF or session would, I think, go over
quite well :)
A question that has been on my mind for a bit, is what does serf
intend to replace, and why is it better?.
The impression I have so far is
On 4/1/08 9:40 AM, Torsten Foertsch [EMAIL PROTECTED] wrote:
I know one can do that. But a VHost has a server_rec, maybe a separate
error_log and access_log, etc. Those cannot be created at request time. That
is what I meant.
Well
I was hacking around with the idea that the selection of
On Tue 01 Apr 2008, Jim Jagielski wrote:
On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
You cannot add virtual servers on the fly
Hmmm let's see now. If we have a default Vhost that all non-matched
name-based hosts get directed to configured, then a mod_perl based
handler can be
Jim Jagielski wrote:
This reminds me: a serf BOF or session would, I think, go over
quite well :)
A question that has been on my mind for a bit, is what does serf intend
to replace, and why is it better?.
The impression I have so far is that somehow what we have now is
suboptimal, and
On Apr 1, 2008, at 9:40 AM, Torsten Foertsch wrote:
On Tue 01 Apr 2008, Jim Jagielski wrote:
On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
You cannot add virtual servers on the fly
Hmmm let's see now. If we have a default Vhost that all non-
matched
name-based hosts get directed
Jorge Schrauwen wrote:
Solutions propose:
- lua in the core or atleast in a module
- mod_perl
mod_perl exists already. We're looking to replace it because... (see below)
Downside:
- perl isn't very easy and userfriendly
I think that the downside is the fact that perl interpreters suck
On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand [EMAIL PROTECTED] wrote:
Jorge Schrauwen wrote:
Solutions propose:
- lua in the core or atleast in a module
- mod_perl
mod_perl exists already. We're looking to replace it because... (see below)
I'm quite aware that it exists, I
Jorge Schrauwen wrote:
On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand [EMAIL PROTECTED] wrote:
Downside:
- perl isn't very easy and userfriendly
I think that the downside is the fact that perl interpreters suck up
RAM, not the easiness factor. It's probably not significantly
On Apr 1, 2008, at 9:36 AM, Jorge Schrauwen wrote:
Let me try and summarize this then:
Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
IMO, based on feedback from people I've dealt with with my
Jim Jagielski wrote:
On Apr 1, 2008, at 9:36 AM, Jorge Schrauwen wrote:
Let me try and summarize this then:
Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
IMO, based on feedback from people I've dealt with
On Apr 1, 2008, at 10:32 AM, Matthew M. Burke wrote:
Graham Leggett wrote:
The trouble is, if I want to solve problem A (configure the
server), and I find out that before I can solve problem A
(configure the server) I need to first solve problem B (learn a
new language), that is a big
Matthew M. Burke wrote:
Graham Leggett wrote:
The trouble is, if I want to solve problem A (configure the server),
and I find out that before I can solve problem A (configure the
server) I need to first solve problem B (learn a new language),
that is a big incentive to just ignore the
Graham Leggett wrote:
The trouble is, if I want to solve problem A (configure the server),
and I find out that before I can solve problem A (configure the
server) I need to first solve problem B (learn a new language),
that is a big incentive to just ignore the new server and stick with
On Tue 01 Apr 2008, Akins, Brian wrote:
In pseudo config, like niq is suggesting, you could have something like:
If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080
#cnn specific stuff here...
DocumentRoot /htdocs/cnn
CutomLog |/usr/bin/logger cnn my_format
ErrorLog
On 4/1/08 11:21 AM, Torsten Foertsch [EMAIL PROTECTED] wrote:
On Tue 01 Apr 2008, Akins, Brian wrote:
In pseudo config, like niq is suggesting, you could have something like:
If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080
#cnn specific stuff here...
DocumentRoot /htdocs/cnn
Jim Jagielski wrote:
I'd prefer optimum runtime and let that drive how it gets exposed to
the admin, rather than the reverse... And then we can see if that
pain is worth it :)
+1 to this as a guiding principle.
I know our administrators would, above all else, like a standard
way to build
On Tue, Apr 1, 2008 at 6:20 AM, Jim Jagielski [EMAIL PROTECTED] wrote:
IMO, we work best when we feel empowered to scratch our itches...
As we've also seen, sometimes all it takes is someone to create
a rough framework of an implementation for people to get excited
by it and jump right on
31 matches
Mail list logo
