Sander Temme wrote:
How many Apache 'D' versions do we want to maintain? Popularity of
1.3 is still too high for us to completely ignore, and there is much
2.0 still out there.
Any many people taking up 2.2...
--
On Feb 19, 2007, at 12:51 PM, Roy T. Fielding wrote:
We work best as a collaboration when we give people the freedom to
explore their own personal wild ideas (or even just reasonable ideas
for which the solution has no clear timeline). If we artificially
constrain the scope of what can be
On Tue, 13 Feb 2007 23:33:27 -0800
Paul Querna [EMAIL PROTECTED] wrote:
So, I've been kicking around some ideas about where I personally would
like trunk to go for a couple months now.
You've missed the most important consideration here.
Namely, don't break everything that's gone before.
On Mon, February 19, 2007 11:44 am, Nick Kew wrote:
You've missed the most important consideration here.
Namely, don't break everything that's gone before.
Specifically, a big -1 on forcing substantial rewrites of
existing applications. Or in other words, the API must
continue to work
Location and User Aware
URL: www.5o9inc.com
-Original Message-
From: Nick Kew [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 2:44 AM
To: dev@httpd.apache.org
Subject: Re: 3.0 - Proposed Goals
On Tue, 13 Feb 2007 23:33:27 -0800
Paul Querna [EMAIL PROTECTED] wrote:
So, I've been
On Feb 19, 2007, at 1:44 AM, Nick Kew wrote:
The breakage between 1.x and 2.0 was far too much. If we
do it again, the world will rightly conclude that Apache
is not a solution fit for the long term.
+1. While it's fun and rewarding to hack on advanced stuff in its
own right, the project
On Feb 19, 2007, at 11:06 AM, Sander Temme wrote:
On Feb 19, 2007, at 1:44 AM, Nick Kew wrote:
The breakage between 1.x and 2.0 was far too much. If we
do it again, the world will rightly conclude that Apache
is not a solution fit for the long term.
+1. While it's fun and rewarding to hack
I have created a file in svn to track the discussion about these ideas,
and others at:
https://svn.apache.org/repos/asf/httpd/sandbox/amsterdam/ROADMAP
As new ideas were added later on in the thread, please add them to this
file.
Paul Querna wrote:
So, I've been kicking around some ideas
- Provide a generic inter-process data-sharing framework. Currently
mod_ssl, mod_auth_digest, mod_ldap, and the scoreboard all use
more-or-less independent implementations of shared memory data stores.
As someone who maintains a module with yet another such data store,
I think a
Am Dienstag, den 13.02.2007, 23:33 -0800 schrieb Paul Querna:
- Build a cleaner configuration system, enabling runtime
reconfiguration. Today's system basically requires a complete restart of
everything to change configurations. I would like to move to an
internal DOM like representation of
Joachim Zobel wrote:
Am Dienstag, den 13.02.2007, 23:33 -0800 schrieb Paul Querna:
- Build a cleaner configuration system, enabling runtime
reconfiguration. Today's system basically requires a complete restart of
everything to change configurations. I would like to move to an
internal DOM
Am Donnerstag, den 15.02.2007, 11:51 -0800 schrieb Paul Querna:
XML isn't important.
But validation is. And it would be really nice to have a uniqueness
constraint for the configuation that makes shure certain settings are
only done once. An error message is really preferrable to a silent
On 2/14/07, Paul Querna [EMAIL PROTECTED] wrote:
- Rewrite how Brigades, Buckets and filters work. Possibly replace them
with other models. I haven't been able to personally consolidate my
thoughts on how to 'fix' filters, but I am sure we can plenty of long
threads about it :-)
I think a
On Feb 14, 2007, at 2:33 AM, Paul Querna wrote:
- Promote and include a external-process communication method in the
core. This could be used to communicate with PHP, a JVM, Ruby or many
other things that do not wish to be run inside a highly-threaded and
async core. The place for large
On Wed, 14 Feb 2007, Garrett Rooney wrote:
- Rewrite how Brigades, Buckets and filters work. Possibly replace them
with other models. I haven't been able to personally consolidate my
thoughts on how to 'fix' filters, but I am sure we can plenty of long
threads about it :-)
I think a big part
On Wed, 14 Feb 2007 15:41:38 +0100 (MET)
Niklas Edmundsson [EMAIL PROTECTED] wrote:
One problem here is that this kind of docco usually needs to be made
by those who hate to write it: the core programmers.
The core programmers use the core programmer documentation,
aka the source code. In
On Wed, 14 Feb 2007, Nick Kew wrote:
On Wed, 14 Feb 2007 15:41:38 +0100 (MET)
Niklas Edmundsson [EMAIL PROTECTED] wrote:
One problem here is that this kind of docco usually needs to be made
by those who hate to write it: the core programmers.
The core programmers use the core programmer
On Feb 14, 2007, at 10:45 AM, Justin Erenkrantz wrote:
On 2/13/07, Paul Querna [EMAIL PROTECTED] wrote:
- Rewrite how Brigades, Buckets and filters work. Possibly
replace them
with other models. I haven't been able to personally consolidate my
thoughts on how to 'fix' filters, but I am
On 2/14/07, Nick Kew [EMAIL PROTECTED] wrote:
One problem here is that this kind of docco usually needs to be made
by those who hate to write it: the core programmers.
The core programmers use the core programmer documentation,
aka the source code. In particular, the .h files, which
give you
Of course if no one wants to do it, we'll have to do with what we've got,
but saying that it's not a problem doesn't seem wise to me.
I punish myself for talking before following the instructions. There are
good docs about module/core development in apachetutor.org.
And they even are
Jim Jagielski wrote:
This makes a lot of sense, but please NOT AJP... It
seems to be that staying with HTTP is the most scalable,
easiest to debug and troubleshoot, and the most straightforward.
Would be nice if we could do HTTP over unix domain sockets, for example. No
need for full TCP
On Wed, Feb 14, 2007 at 01:57:27PM -0500, Brian Akins wrote:
Would be nice if we could do HTTP over unix domain sockets, for example.
No need for full TCP stack just to pass things back and forth between
Apache and back-end processes.
Or over standard input, so that we can have an admin
Paul Querna wrote:
So, I've been kicking around some ideas about where I personally would
like trunk to go for a couple months now.
My personal goals for 3.0:
- Write some cool stuff, that is fun to hack on.
- Create an environment that encourages others to contribute, A project
this
On Feb 14, 2007, at 3:28 PM, William A. Rowe, Jr. wrote:
It's always been small groups ;-) But we are loathe to drop the
'barrier
to entry' of demonstrating that the new coder is 'cluefull'. This
is a
server platform, rife with the security issues that go along with
that.
We need
Jim Jagielski wrote:
On Feb 14, 2007, at 3:28 PM, William A. Rowe, Jr. wrote:
It's always been small groups ;-) But we are loathe to drop the 'barrier
to entry' of demonstrating that the new coder is 'cluefull'. This is a
server platform, rife with the security issues that go along with
On Wed, Feb 14, 2007 at 07:08:32PM +, Colm MacCarthaigh wrote:
On Wed, Feb 14, 2007 at 01:57:27PM -0500, Brian Akins wrote:
Would be nice if we could do HTTP over unix domain sockets, for example.
No need for full TCP stack just to pass things back and forth between
Apache and
Hi --
Paul Querna wrote:
- Rewrite the Core to be an Async Event state machine and data router.
- Break the 1:1 mapping of a worker to a single request.
- Change the meaning of MPMs. The problem with MPMs today is they are
really mostly platform abstractions -- not just abstractions of the
27 matches
Mail list logo
