You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/01/27 08:41:35 UTC
beta?
We are now running 2.0 on apache.org. The code should be relatively
stable at this point. I am not really sure what Roy's new release model
means for betas, but I want one, ASAP.
So, here is what I would ask for. There are a couple of patches still out
there. Let's do what it takes to commit them over the next week, and in
the first week of February, the week of 5th, let's shoot for a beta
release. I would suggest we do it next week, but I believe a lot of us
will be in NY for LinuxWorld.
I will volunteer to be RM, including taking a stab at Roy's new model if
he would like me to. What that means, is that I would roll a tarball on
Monday of this week, and again Moday the 5th, and the 12th. The first
tarball we have of beta quality gets named a beta. At least, that is how
I understand the process. Roy, am I right? Obviously, this would also
require some changes to the code, so that we can easily change our current
version.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Jeff Trawick" <tr...@bellsouth.net>
Sent: Saturday, January 27, 2001 9:13 AM
> I don't really like such formalisms, but I'd like to see things slow
> down drastically leading up to beta 1.
I'm -1 on phasing into RTC. And I'm -1 on stopping -new-efforts- until
the 24 hour cycle in which we roll the tarball (T-2400 and counting,
till we roll.) Those 'fixes' to get the tarball to build in that timeframe
can't be RTC, they need to be applied and go forward.
If the tarball of b1 is broken, then we roll again. This isn't a 'stable'
product (a la 1.3), this is a development tree till we rubber-stamp a real
_2_0_0_gold release :-)
I think this is precisely the issue that Roy's reorg will solve. We don't
waste users time advertising a release (alpha, beta, gold) that we aren't
sure is solid. We announce alphas to the dev list, betas and gold
'certifications' to the apache-announce list. We can take 12 hours or 12
days to make those determinations, as the circumstances demand.
> As always, best wishes to everyone regardless of your opinion :)
And good work twords making this beta, Jeff! Thanks for you efforts :-)
Re: beta?
Posted by James Sutherland <ja...@cam.ac.uk>.
On Sun, 28 Jan 2001, David Reid wrote:
> > The question is, what "protocol" to use? Just sending a struct describing
> > what's going on is one option; have each process send to a socket
> > (UDP??) with the monitoring module/process running on?
>
> Bear in mind we don't have UDP support in APR yet...
Last time I looked, we didn't have the rest of the idea yet either :-)
TCP would do, though. Might even be preferable - greater overhead, but we
know the data gets there. Also avoids issues with packet size etc.
James.
Re: beta?
Posted by David Reid <dr...@jetnet.co.uk>.
> The question is, what "protocol" to use? Just sending a struct describing
> what's going on is one option; have each process send to a socket
> (UDP??) with the monitoring module/process running on?
Bear in mind we don't have UDP support in APR yet...
david
Re: beta?
Posted by James Sutherland <ja...@cam.ac.uk>.
On Mon, 29 Jan 2001 rbb@covalent.net wrote:
>
> > > > The question is, what "protocol" to use? Just sending a struct describing
> > > > what's going on is one option; have each process send to a socket
> > > > (UDP??) with the monitoring module/process running on?
> > >
> > > This is solution that works.
> > >
> > > However, I also miss still a protocol field in the
> > > server_rec. If Apache can support multiple protocol
> > > via protocol modules it is my opinion that each
> > > server ('server_rec') needs to know which protocol
> > > it serves.
> >
> > ?? So how come mod_echo works without one of these?
>
> We don't need it, and in fact it would be very difficult to get it
> right. Which protocols do we support? What happens when a new protocol
> is added? I believe this field will end up being a major headache without
> a major gain. The mod_status stuff will most likely want this field, but
> that is strictly for reporting, not for anything else.
At least for the near future, I'd have said the port number would be more
use: most multi-port configs will be either vhosts (I have the various
Apache site CVS trees on :80, and the beginnings of a validator.w3.org
mirror on :81), in which case the port is more use than the protocol, or
HTTP/HTTPS, in which case it's often clear which is which - 80 vs 443.
Maybe later, when there's a mod_ftp, mod_imap, mod_smtp in common use :-)
James.
Re: beta?
Posted by rb...@covalent.net.
> > > The question is, what "protocol" to use? Just sending a struct describing
> > > what's going on is one option; have each process send to a socket
> > > (UDP??) with the monitoring module/process running on?
> >
> > This is solution that works.
> >
> > However, I also miss still a protocol field in the
> > server_rec. If Apache can support multiple protocol
> > via protocol modules it is my opinion that each
> > server ('server_rec') needs to know which protocol
> > it serves.
>
> ?? So how come mod_echo works without one of these?
We don't need it, and in fact it would be very difficult to get it
right. Which protocols do we support? What happens when a new protocol
is added? I believe this field will end up being a major headache without
a major gain. The mod_status stuff will most likely want this field, but
that is strictly for reporting, not for anything else.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
David Williams wrote:
> > > So that a
> > > given server process (e.g. child_main() in prefork.c) could handle multiple
> > > protocols, which could all be sent to the same port if desired.
> >
> > How would it know which one to handle, then?
>
> It has been a while since I looked at this part of the code, and I suspect there is not enough coordination between the potential
> callouts that hooked into ap_run_process_connection(). But I had gotten the idea that in theory, each callout could look at the
> incoming request (raw PDU) and determine if it knew how to handle it. Returning DECLINED until the right protocol handler was
> found. Basically laying the foundation for apache to become a server of many protocols, through a universal addr/port. ;-)
>
> I agree that different protocols would normally use separate ports, but prehaps there are issues getting through a firewall.
> Instead of being data sensitive, I suppose each process_connection callout is expected to look at the fd/port used and DECLINE based
> on that.
Exactly.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
RE: beta?
Posted by David Williams <dw...@cisco.com>.
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> David Williams wrote:
> >
> > > From: Ben Laurie [mailto:ben@algroup.co.uk]
> > > > > > James Sutherland wrote:
> > > > > > [snip]
> > > > > > >
> > > > > > > The question is, what "protocol" to use? Just sending a
> > > > > struct describing
> > > > > > > what's going on is one option; have each process send to a socket
> > > > > > > (UDP??) with the monitoring module/process running on?
> > > > > >
> > > > > > This is solution that works.
> > > > > >
> > > > > > However, I also miss still a protocol field in the
> > > > > > server_rec. If Apache can support multiple protocol
> > > > > > via protocol modules it is my opinion that each
> > > > > > server ('server_rec') needs to know which protocol
> > > > > > it serves.
> > > >
> > > > Seems that each server does need to know which protocol it is capable of
> > > > serving. And in cases where it supports multiple ones, use the
> > > > request_rec->protocol field to determine how to handle that particular
> > > > request.
> > >
> > > Now you've lost me ... a "server" in this context is a binding of an IP
> > > address and port - it inherently "knows" what it should do through the
> > > configuration (which is derived from that binding).
> >
> > I am under the impression that ap_hook_process_connection() was provided to
> > allow non-http protocol modules to hook into the processing path?
>
> Yes.
>
> > So that a
> > given server process (e.g. child_main() in prefork.c) could handle multiple
> > protocols, which could all be sent to the same port if desired.
>
> How would it know which one to handle, then?
It has been a while since I looked at this part of the code, and I suspect there is not enough coordination between the potential
callouts that hooked into ap_run_process_connection(). But I had gotten the idea that in theory, each callout could look at the
incoming request (raw PDU) and determine if it knew how to handle it. Returning DECLINED until the right protocol handler was
found. Basically laying the foundation for apache to become a server of many protocols, through a universal addr/port. ;-)
I agree that different protocols would normally use separate ports, but prehaps there are issues getting through a firewall.
Instead of being data sensitive, I suppose each process_connection callout is expected to look at the fd/port used and DECLINE based
on that.
>
> > > > > ?? So how come mod_echo works without one of these?
> > > >
> > > > mod_echo might not be the best example, since it doesn't care about the
> > > > protocol at all, simply echoing what was received.
> > >
> > > Errr ... and how is this not a protocol? Wouldn't you be a little upset
> > > if your webserver thought that's what it should do?
> >
> > I meant mod_echo is not a protocol in the sense that it cares about request.
> > It would treat
> > GET http://www.foo.org HTTP/1.1
> > METHOD_X New_Transport_Protocol:Resource_locator NTP/1.0
> > the same and hijack the incoming request. Where as a more protocol aware
> > module would examine the PDU and decline the request if it doesn't
> > understand it. Giving ap_process_http_connection() or other protocol
> > modules a chance to handle it.
>
> Ah. You are talking about a protocol of a different kind. Clearly you
> have to know in advance that the client is going to select a protocol in
> its request - and _that's_ the protocol you handle in
> ap_hook_process_connection(). If you then want to hand off to a
> sub-protocol you need your own hooking mechanism to do that, I'd say
> (which would be dependent on the initial protocol). This would,
> presumably, use an optional hook (damn, can I rename generic hooks to
> optional hooks without getting shot?).
Yes! One of the nice things about 2.0 is the ability for a module to define a new set of hooks to be plugged into.
-david
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
David Williams wrote:
>
> > From: Ben Laurie [mailto:ben@algroup.co.uk]
> > > > > James Sutherland wrote:
> > > > > [snip]
> > > > > >
> > > > > > The question is, what "protocol" to use? Just sending a
> > > > struct describing
> > > > > > what's going on is one option; have each process send to a socket
> > > > > > (UDP??) with the monitoring module/process running on?
> > > > >
> > > > > This is solution that works.
> > > > >
> > > > > However, I also miss still a protocol field in the
> > > > > server_rec. If Apache can support multiple protocol
> > > > > via protocol modules it is my opinion that each
> > > > > server ('server_rec') needs to know which protocol
> > > > > it serves.
> > >
> > > Seems that each server does need to know which protocol it is capable of
> > > serving. And in cases where it supports multiple ones, use the
> > > request_rec->protocol field to determine how to handle that particular
> > > request.
> >
> > Now you've lost me ... a "server" in this context is a binding of an IP
> > address and port - it inherently "knows" what it should do through the
> > configuration (which is derived from that binding).
>
> I am under the impression that ap_hook_process_connection() was provided to
> allow non-http protocol modules to hook into the processing path?
Yes.
> So that a
> given server process (e.g. child_main() in prefork.c) could handle multiple
> protocols, which could all be sent to the same port if desired.
How would it know which one to handle, then?
> > > > ?? So how come mod_echo works without one of these?
> > >
> > > mod_echo might not be the best example, since it doesn't care about the
> > > protocol at all, simply echoing what was received.
> >
> > Errr ... and how is this not a protocol? Wouldn't you be a little upset
> > if your webserver thought that's what it should do?
>
> I meant mod_echo is not a protocol in the sense that it cares about request.
> It would treat
> GET http://www.foo.org HTTP/1.1
> METHOD_X New_Transport_Protocol:Resource_locator NTP/1.0
> the same and hijack the incoming request. Where as a more protocol aware
> module would examine the PDU and decline the request if it doesn't
> understand it. Giving ap_process_http_connection() or other protocol
> modules a chance to handle it.
Ah. You are talking about a protocol of a different kind. Clearly you
have to know in advance that the client is going to select a protocol in
its request - and _that's_ the protocol you handle in
ap_hook_process_connection(). If you then want to hand off to a
sub-protocol you need your own hooking mechanism to do that, I'd say
(which would be dependent on the initial protocol). This would,
presumably, use an optional hook (damn, can I rename generic hooks to
optional hooks without getting shot?).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
RE: beta?
Posted by David Williams <dw...@cisco.com>.
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> > > > James Sutherland wrote:
> > > > [snip]
> > > > >
> > > > > The question is, what "protocol" to use? Just sending a
> > > struct describing
> > > > > what's going on is one option; have each process send to a socket
> > > > > (UDP??) with the monitoring module/process running on?
> > > >
> > > > This is solution that works.
> > > >
> > > > However, I also miss still a protocol field in the
> > > > server_rec. If Apache can support multiple protocol
> > > > via protocol modules it is my opinion that each
> > > > server ('server_rec') needs to know which protocol
> > > > it serves.
> >
> > Seems that each server does need to know which protocol it is capable of
> > serving. And in cases where it supports multiple ones, use the
> > request_rec->protocol field to determine how to handle that particular
> > request.
>
> Now you've lost me ... a "server" in this context is a binding of an IP
> address and port - it inherently "knows" what it should do through the
> configuration (which is derived from that binding).
I am under the impression that ap_hook_process_connection() was provided to
allow non-http protocol modules to hook into the processing path? So that a
given server process (e.g. child_main() in prefork.c) could handle multiple
protocols, which could all be sent to the same port if desired.
>
> >
> > > ?? So how come mod_echo works without one of these?
> >
> > mod_echo might not be the best example, since it doesn't care about the
> > protocol at all, simply echoing what was received.
>
> Errr ... and how is this not a protocol? Wouldn't you be a little upset
> if your webserver thought that's what it should do?
I meant mod_echo is not a protocol in the sense that it cares about request.
It would treat
GET http://www.foo.org HTTP/1.1
METHOD_X New_Transport_Protocol:Resource_locator NTP/1.0
the same and hijack the incoming request. Where as a more protocol aware
module would examine the PDU and decline the request if it doesn't
understand it. Giving ap_process_http_connection() or other protocol
modules a chance to handle it.
-david
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
David Williams wrote:
>
> > -----Original Message-----
> > From: Ben Laurie [mailto:ben@algroup.co.uk]
> > Sent: Monday, January 29, 2001 15:58
> > Harrie Hazewinkel wrote:
> > >
> > > James Sutherland wrote:
> > > [snip]
> > > >
> > > > The question is, what "protocol" to use? Just sending a
> > struct describing
> > > > what's going on is one option; have each process send to a socket
> > > > (UDP??) with the monitoring module/process running on?
> > >
> > > This is solution that works.
> > >
> > > However, I also miss still a protocol field in the
> > > server_rec. If Apache can support multiple protocol
> > > via protocol modules it is my opinion that each
> > > server ('server_rec') needs to know which protocol
> > > it serves.
>
> Seems that each server does need to know which protocol it is capable of
> serving. And in cases where it supports multiple ones, use the
> request_rec->protocol field to determine how to handle that particular
> request.
Now you've lost me ... a "server" in this context is a binding of an IP
address and port - it inherently "knows" what it should do through the
configuration (which is derived from that binding).
>
> > ?? So how come mod_echo works without one of these?
>
> mod_echo might not be the best example, since it doesn't care about the
> protocol at all, simply echoing what was received.
Errr ... and how is this not a protocol? Wouldn't you be a little upset
if your webserver thought that's what it should do?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: beta?
Posted by Harrie Hazewinkel <ha...@covalent.net>.
David Williams wrote:
>
> > -----Original Message-----
> > From: Ben Laurie [mailto:ben@algroup.co.uk]
> > Sent: Monday, January 29, 2001 15:58
> > Harrie Hazewinkel wrote:
> > >
> > > James Sutherland wrote:
> > > [snip]
> > > >
> > > > The question is, what "protocol" to use? Just sending a
> > struct describing
> > > > what's going on is one option; have each process send to a socket
> > > > (UDP??) with the monitoring module/process running on?
> > >
> > > This is solution that works.
OK, I maybe misstated it. Yes it works, but for future protocols
you cannot easily combine vhosts with protocols
My understanding now of it is that protocol_modules must say
"yes, this protocol is supported". I still beleive that a better
seperation between the protocol and server_rec is a good idea.
This definitly allows better management of the server
with modules like mod_status.
> > >
> > > However, I also miss still a protocol field in the
> > > server_rec. If Apache can support multiple protocol
> > > via protocol modules it is my opinion that each
> > > server ('server_rec') needs to know which protocol
> > > it serves.
>
> Seems that each server does need to know which protocol it is capable of
> serving. And in cases where it supports multiple ones, use the
> request_rec->protocol field to determine how to handle that particular
> request.
This does not work if you want to provide statistics like mod_status
or even mod_snmp. When you want to provide the statistics for a
service (vhost/server_rec) the request you have is most likely _NOT_ the
protocol it had served and match the statistics you want to return.
IMHO, this is not the solution for statistics.
>
> > ?? So how come mod_echo works without one of these?
>
> mod_echo might not be the best example, since it doesn't care about the
> protocol at all, simply echoing what was received.
>
> -david
>
> >
> > Cheers,
> >
> > Ben.
> >
> > --
> > http://www.apache-ssl.org/ben.html
> >
> > "There is no limit to what a man can do or how far he can go if he
> > doesn't mind who gets the credit." - Robert Woodruff
> >
RE: beta?
Posted by David Williams <dw...@cisco.com>.
> -----Original Message-----
> From: Ben Laurie [mailto:ben@algroup.co.uk]
> Sent: Monday, January 29, 2001 15:58
> Harrie Hazewinkel wrote:
> >
> > James Sutherland wrote:
> > [snip]
> > >
> > > The question is, what "protocol" to use? Just sending a
> struct describing
> > > what's going on is one option; have each process send to a socket
> > > (UDP??) with the monitoring module/process running on?
> >
> > This is solution that works.
> >
> > However, I also miss still a protocol field in the
> > server_rec. If Apache can support multiple protocol
> > via protocol modules it is my opinion that each
> > server ('server_rec') needs to know which protocol
> > it serves.
Seems that each server does need to know which protocol it is capable of
serving. And in cases where it supports multiple ones, use the
request_rec->protocol field to determine how to handle that particular
request.
> ?? So how come mod_echo works without one of these?
mod_echo might not be the best example, since it doesn't care about the
protocol at all, simply echoing what was received.
-david
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
Harrie Hazewinkel wrote:
>
> James Sutherland wrote:
> [snip]
> >
> > The question is, what "protocol" to use? Just sending a struct describing
> > what's going on is one option; have each process send to a socket
> > (UDP??) with the monitoring module/process running on?
>
> This is solution that works.
>
> However, I also miss still a protocol field in the
> server_rec. If Apache can support multiple protocol
> via protocol modules it is my opinion that each
> server ('server_rec') needs to know which protocol
> it serves.
?? So how come mod_echo works without one of these?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: beta?
Posted by Harrie Hazewinkel <ha...@covalent.net>.
James Sutherland wrote:
[snip]
>
> The question is, what "protocol" to use? Just sending a struct describing
> what's going on is one option; have each process send to a socket
> (UDP??) with the monitoring module/process running on?
This is solution that works.
However, I also miss still a protocol field in the
server_rec. If Apache can support multiple protocol
via protocol modules it is my opinion that each
server ('server_rec') needs to know which protocol
it serves.
This could be fixed by just adding an integer that
provides the well-known port as protocol identification.
The current 'port'-field in the server_rec is not
sufficient, since it provide the port to which it is
connected. When the standard HTTP-port (80) is used
the match to the protocol is perfect, but it is not
if I use port 8888 for the HTTP-port.
Harrie
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > > That sounds good: a generic API to allow each module to report what it's
> > > up to. Maybe even have it work across the network, so I could look at the
> > > status of a cluster of machines??
> >
> > You need Splash!
>
> You just couldn't resist, could you Ben? :-)
Well, it is a perfect fit for the problem. Perhaps we should have a
mod_splash_status?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: beta?
Posted by James Sutherland <ja...@cam.ac.uk>.
Ryan:
> Ben Laurie:
> > Me:
> > > That sounds good: a generic API to allow each module to report what it's
> > > up to. Maybe even have it work across the network, so I could look at the
> > > status of a cluster of machines??
> >
> > You need Splash!
>
> You just couldn't resist, could you Ben? :-)
I thought we were talking about sockets, not plugs? :-)
James.
Re: beta?
Posted by rb...@covalent.net.
> > That sounds good: a generic API to allow each module to report what it's
> > up to. Maybe even have it work across the network, so I could look at the
> > status of a cluster of machines??
>
> You need Splash!
You just couldn't resist, could you Ben? :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
James Sutherland wrote:
>
> On Sun, 28 Jan 2001, Manoj Kasichainula wrote:
>
> > On Sat, Jan 27, 2001 at 04:02:23PM -0800, rbb@covalent.net wrote:
> > > mod_status is a big PITA with the MPMs.
> >
> > I think that the problem could be simplified greatly by eliminating
> > some of the flexibility that was one of the goals of the current 2.0
> > status stuff. If things like multiprotocol support and arbitrary
> > module columns are eliminated, then there can be a fixed set of status
> > fields, like in 1.3, and a lot of problems go away. Not that I think
> > that's necessarily a good thing, but it's better than what's there now.
> >
> > Another possibility is to change the status API to be something
> > provided by a module instead of the MPMs. This module could spawn a
> > seperate process to handle storage and retrieval of the status values.
> > Then the silly shared memory limits go away. This is basically what
> > Dean wants. :) The module could even store these status fields in an
> > SQL database if we wanted to get scary. It's easier now that (if I
> > read things correctly) cross-module calls have been standardized. This
> > would probably be a post-beta thing though.
>
> That sounds good: a generic API to allow each module to report what it's
> up to. Maybe even have it work across the network, so I could look at the
> status of a cluster of machines??
You need Splash!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: beta?
Posted by rb...@covalent.net.
> > > The question is, what "protocol" to use? Just sending a struct describing
> > > what's going on is one option; have each process send to a socket
> > > (UDP??) with the monitoring module/process running on?
> >
> > This is beyond the scope of mod_status. You are basically asking for
> > mod_snmp, and I don't think we want to get into doing that.
>
> Yes, that would be overkill... just a way for each process/thread to
> report what was given at the bottom of /server-status was what I
> wanted. Just fire the corresponding struct off to mod_status over some
> link - sounds OK?? (The question is, WHAT link??)
The whole idea of mod_status dealing with clustering is overkill
IMHO. There is a protocol to handle that, and we don't want to implement
it. The web server itself should just continue to use shared memory as it
did in 1.3.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by James Sutherland <ja...@cam.ac.uk>.
On Sun, 28 Jan 2001 rbb@covalent.net wrote:
>
> > That sounds good: a generic API to allow each module to report what it's
> > up to. Maybe even have it work across the network, so I could look at the
> > status of a cluster of machines??
> >
> > Map the current idle/listening/sending/whatever state into a list of
> > objects (processes/threads/whatevers), each of which send updates to
> > mod_status?
> >
> > The question is, what "protocol" to use? Just sending a struct describing
> > what's going on is one option; have each process send to a socket
> > (UDP??) with the monitoring module/process running on?
>
> This is beyond the scope of mod_status. You are basically asking for
> mod_snmp, and I don't think we want to get into doing that.
Yes, that would be overkill... just a way for each process/thread to
report what was given at the bottom of /server-status was what I
wanted. Just fire the corresponding struct off to mod_status over some
link - sounds OK?? (The question is, WHAT link??)
James.
Re: beta?
Posted by rb...@covalent.net.
> That sounds good: a generic API to allow each module to report what it's
> up to. Maybe even have it work across the network, so I could look at the
> status of a cluster of machines??
>
> Map the current idle/listening/sending/whatever state into a list of
> objects (processes/threads/whatevers), each of which send updates to
> mod_status?
>
> The question is, what "protocol" to use? Just sending a struct describing
> what's going on is one option; have each process send to a socket
> (UDP??) with the monitoring module/process running on?
This is beyond the scope of mod_status. You are basically asking for
mod_snmp, and I don't think we want to get into doing that.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by James Sutherland <ja...@cam.ac.uk>.
On Sun, 28 Jan 2001, Manoj Kasichainula wrote:
> On Sat, Jan 27, 2001 at 04:02:23PM -0800, rbb@covalent.net wrote:
> > mod_status is a big PITA with the MPMs.
>
> I think that the problem could be simplified greatly by eliminating
> some of the flexibility that was one of the goals of the current 2.0
> status stuff. If things like multiprotocol support and arbitrary
> module columns are eliminated, then there can be a fixed set of status
> fields, like in 1.3, and a lot of problems go away. Not that I think
> that's necessarily a good thing, but it's better than what's there now.
>
> Another possibility is to change the status API to be something
> provided by a module instead of the MPMs. This module could spawn a
> seperate process to handle storage and retrieval of the status values.
> Then the silly shared memory limits go away. This is basically what
> Dean wants. :) The module could even store these status fields in an
> SQL database if we wanted to get scary. It's easier now that (if I
> read things correctly) cross-module calls have been standardized. This
> would probably be a post-beta thing though.
That sounds good: a generic API to allow each module to report what it's
up to. Maybe even have it work across the network, so I could look at the
status of a cluster of machines??
Map the current idle/listening/sending/whatever state into a list of
objects (processes/threads/whatevers), each of which send updates to
mod_status?
The question is, what "protocol" to use? Just sending a struct describing
what's going on is one option; have each process send to a socket
(UDP??) with the monitoring module/process running on?
James.
Re: beta?
Posted by rb...@covalent.net.
> > The threaded MPM should take a
> > few hours, just enough time to test that SuEXEC is working correctly.
>
> Does FreeBSD suffer from the fork() delays in threaded apps? If not,
> can it just run mod_cgi and avoid the problem entirely?
I already did the work, I just haven't had the time to really test it
yet. I should be able to test it tonight sometime. mod_cgid is calling
ap_os_create_priviledged_process, so I believe this will just work, but I
desperately want to test it better first.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Manoj Kasichainula <ma...@io.com>.
On Sat, Jan 27, 2001 at 04:02:23PM -0800, rbb@covalent.net wrote:
> mod_status is a big PITA with the MPMs.
I think that the problem could be simplified greatly by eliminating
some of the flexibility that was one of the goals of the current 2.0
status stuff. If things like multiprotocol support and arbitrary
module columns are eliminated, then there can be a fixed set of status
fields, like in 1.3, and a lot of problems go away. Not that I think
that's necessarily a good thing, but it's better than what's there now.
Another possibility is to change the status API to be something
provided by a module instead of the MPMs. This module could spawn a
seperate process to handle storage and retrieval of the status values.
Then the silly shared memory limits go away. This is basically what
Dean wants. :) The module could even store these status fields in an
SQL database if we wanted to get scary. It's easier now that (if I
read things correctly) cross-module calls have been standardized. This
would probably be a post-beta thing though.
> The threaded MPM should take a
> few hours, just enough time to test that SuEXEC is working correctly.
Does FreeBSD suffer from the fork() delays in threaded apps? If not,
can it just run mod_cgi and avoid the problem entirely?
Re: beta?
Posted by rb...@covalent.net.
> > I understand that, but remember, that these features, and things that
> > people said we couldn't go beta without. Dean and Bill said we couldn't
> > go beta with the ap_r* performance we had. We absolutely can't go beta
> > with seg faults whenever we make byterange requests. I would prefer if we
> > didn't go beta if people can't write useful modules.
>
> Personally, I would prefer to be running a threaded mpm on apache.org
> before going beta, and a useful mod_status output, but I won't push it.
mod_status is a big PITA with the MPMs. The threaded MPM should take a
few hours, just enough time to test that SuEXEC is working correctly. The
biggest problem with running the threaded MPM on apache.org, is finding
and fixing seg faults when something does go wrong. Although, it is
possible, since the biggest issues should be with protocol, not threading.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Brian Behlendorf <br...@collab.net>.
On Sat, 27 Jan 2001 rbb@covalent.net wrote:
> I understand that, but remember, that these features, and things that
> people said we couldn't go beta without. Dean and Bill said we couldn't
> go beta with the ap_r* performance we had. We absolutely can't go beta
> with seg faults whenever we make byterange requests. I would prefer if we
> didn't go beta if people can't write useful modules.
Personally, I would prefer to be running a threaded mpm on apache.org
before going beta, and a useful mod_status output, but I won't push it.
Brian
Re: beta?
Posted by rb...@covalent.net.
> > Remember that 99% of the changes that have been committed in the last two
> > weeks, were changes to make the server ready for beta. We are essentially
> > in feature freeze, so unless a feature is necessary, for performance, or
> > protocol correctness, or just so that people can actually write handlers
> > and filters, the code should not be committed.
>
> that is no feature freeze :) many if not most features fit that
> description in some way or another
>
> I just think that deferring new features, however useful, until after
> b1 will move us more quickly towards the point where more people will
> use apache 2.0 and we will begin finding the sorts of problems which
> we can't find ourselves.
I understand that, but remember, that these features, and things that
people said we couldn't go beta without. Dean and Bill said we couldn't
go beta with the ap_r* performance we had. We absolutely can't go beta
with seg faults whenever we make byterange requests. I would prefer if we
didn't go beta if people can't write useful modules.
I agree there are minimal things that don't fit into those categories, but
I still think those are the things we want to allow in while we move
towards beta.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> Remember that 99% of the changes that have been committed in the last two
> weeks, were changes to make the server ready for beta. We are essentially
> in feature freeze, so unless a feature is necessary, for performance, or
> protocol correctness, or just so that people can actually write handlers
> and filters, the code should not be committed.
that is no feature freeze :) many if not most features fit that
description in some way or another
I just think that deferring new features, however useful, until after
b1 will move us more quickly towards the point where more people will
use apache 2.0 and we will begin finding the sorts of problems which
we can't find ourselves.
later,
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: beta?
Posted by rb...@covalent.net.
> I would like to see us put a brake on unnecessary patches so that
> everybody runs mostly the same code for a while and we figure out what
> is actually broken. We've broken the build a few times in the last
> week, we've introduced new breakage, so extra work has been devoted to
> fixing snafus. While that is usually to be expected, it makes it hard
> to concentrate on a beta because things are changing so quickly. I'd
> rather spend time finding ways to crash the server than looking into
> e-mails from regression test machines complaining that they won't
> build or some test failed.
Remember that 99% of the changes that have been committed in the last two
weeks, were changes to make the server ready for beta. We are essentially
in feature freeze, so unless a feature is necessary, for performance, or
protocol correctness, or just so that people can actually write handlers
and filters, the code should not be committed. Show me a patch that
doesn't fit into one of those three categories, and I'll agree with you
100%. IMHO, the only change that is questionable, is the error_bucket
change I made last night, and that is necessary for me to be able to
continue to write filters, so it must be necessary for others as well.
> For core Apache code and modules such as cgi[d], mime, autoindex,
> include, rewrite, etc. (I'm not too concerned with miscellaneous
> modules; they may or may not work as it stands anyway) as well as key
> bits of APR (most of it), I'd like to see 2 +1s prior to any commit
> (other than to fix a compile breakage or some warning that cropped up
> on some compiler after a commit). Hopefully this means that if the
> change doesn't fix a real problem it won't go in. After beta 1 is
> released, we can loosen things up again.
You are asking for review then commit. This slows things down a lot. I
personally believe that just going into feature freeze is good enough, but
I am willing to go into RTC. However, if we are going to RTC, then we
should follow the guidelines, and require threee +1's.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Greg Ames <gr...@raleigh.ibm.com>.
Brian Behlendorf wrote:
>
> On Sat, 27 Jan 2001 rbb@covalent.net wrote:
> > I should have a fix in a few minutes. Brian, we should update the server
> > later tonight to catch this, and a simple protocol error that was caught
> > yesterday.
>
> Cool. Greg, are you around to do another build?
>
> Brian
I'm around now...no Apache or IBM e-mail access this weekend, and a new
motherboard etc to distract me & cut off most of my Internet access
altogether.
Let me catch up on the commits and see if the known seg fault is really
fixed, build, and test. I'll let everybody know when I'm happy with
another build.
Greg
Re: beta?
Posted by Brian Behlendorf <br...@collab.net>.
On Sat, 27 Jan 2001 rbb@covalent.net wrote:
> I should have a fix in a few minutes. Brian, we should update the server
> later tonight to catch this, and a simple protocol error that was caught
> yesterday.
Cool. Greg, are you around to do another build?
Brian
Re: beta?
Posted by rb...@covalent.net.
> On Sat, 27 Jan 2001 rbb@covalent.net wrote:
> > Okay, fully diagnosed now. Brian, we are seg faulting on EVERY HEAD
> > request to the server. It is up to you if you want to take it down or
> > not. I'll have a fix committed in a few minutes.
>
> Hmm, I'm able to send a "HEAD / HTTP/1.0" directly to port 80 just fine,
> but cool that you see the problem. Since Greg Ames did the build I don't
> want to stomp over his process - Greg, are you around this weekend?
We may only segfault if the includes filter actually has to hold up
data. That would happen whenever we do an include virtual.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Brian Behlendorf <br...@collab.net>.
On Sat, 27 Jan 2001 rbb@covalent.net wrote:
> Okay, fully diagnosed now. Brian, we are seg faulting on EVERY HEAD
> request to the server. It is up to you if you want to take it down or
> not. I'll have a fix committed in a few minutes.
Hmm, I'm able to send a "HEAD / HTTP/1.0" directly to port 80 just fine,
but cool that you see the problem. Since Greg Ames did the build I don't
want to stomp over his process - Greg, are you around this weekend?
Brian
Re: beta?
Posted by rb...@covalent.net.
Okay, fully diagnosed now. Brian, we are seg faulting on EVERY HEAD
request to the server. It is up to you if you want to take it down or
not. I'll have a fix committed in a few minutes.
Ryan
On Sat, 27 Jan 2001 rbb@covalent.net wrote:
>
> > Have a gander over in /usr/local/apache2/corefiles on apache.org, then -
> > so far I've reaped about 100 core files, and they're readable by anyone on
> > the system. It's infrequent enough that I've not put 1.3 back up, but
> > it's often enough that it's worth looking into.
>
> I have just looked at 13 core files. Wow, they all died at the exact same
> location. :-) The problem is easy, although I haven't actually traced
> any code, so I'm not sure how to fix it yet. The problem is that we have
> a HEAD request, and now content-length in headers_out. The problem is we
> do a apr_table_get(r->headers_out, "Content_Length"), and then do a
> strcmp on that value. If that's NULL...... BOOM!
>
> I should have a fix in a few minutes. Brian, we should update the server
> later tonight to catch this, and a simple protocol error that was caught
> yesterday.
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by rb...@covalent.net.
> Have a gander over in /usr/local/apache2/corefiles on apache.org, then -
> so far I've reaped about 100 core files, and they're readable by anyone on
> the system. It's infrequent enough that I've not put 1.3 back up, but
> it's often enough that it's worth looking into.
I have just looked at 13 core files. Wow, they all died at the exact same
location. :-) The problem is easy, although I haven't actually traced
any code, so I'm not sure how to fix it yet. The problem is that we have
a HEAD request, and now content-length in headers_out. The problem is we
do a apr_table_get(r->headers_out, "Content_Length"), and then do a
strcmp on that value. If that's NULL...... BOOM!
I should have a fix in a few minutes. Brian, we should update the server
later tonight to catch this, and a simple protocol error that was caught
yesterday.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> I believe that SIGWINCH isn't available on all Unixes, so prefork
> needs to stick with SIGUSR1.
I don't think it is safe to use SIGWINCH in any case.
> I would support dropping support for threads under Linux 2.0 to make
> SIGUSR1 available for everything.
>
> Another alternative would be to add the Windows signalling flags ("-k
> shutdown", "-k restart", etc. last I checked) to the Unix side, so
> that we can use whatever signals we want. This has the added benefit
> of eliminating a difference between Unix and Windows.
I was just working on making it a compile-time define. The problem
with making it run-time defined is that then a process control
script needs to know what command-line was used to start httpd.
*shrug*
....Roy
Re: beta?
Posted by rb...@covalent.net.
> > Joshua, you are preaching to the choir. If we make them the same, it
> > needs to be SIGWINCH. I can do that easily enough, but I need more buy-in
> > before I do.
>
> I believe that SIGWINCH isn't available on all Unixes, so prefork
> needs to stick with SIGUSR1.
If SIGWINCH isn't available, then we need to choose a different signal for
all MPMs.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Manoj Kasichainula <ma...@io.com>.
On Sat, Jan 27, 2001 at 09:38:20AM -0800, rbb@covalent.net wrote:
>
> > > Nope, -USR1 should have done it. This is a bit annoying, we have to use
> > > two different signals, one for threaded versions, one for
> > > non-threaded. Prefork uses SIGUSR1 because that's what 1.3
> > > did. MPMT_pthread and dexter us SIGWINCH, because that doesn't collide
> > > with old versions of Linux.
> > >
> Joshua, you are preaching to the choir. If we make them the same, it
> needs to be SIGWINCH. I can do that easily enough, but I need more buy-in
> before I do.
I believe that SIGWINCH isn't available on all Unixes, so prefork
needs to stick with SIGUSR1.
I would support dropping support for threads under Linux 2.0 to make
SIGUSR1 available for everything.
Another alternative would be to add the Windows signalling flags ("-k
shutdown", "-k restart", etc. last I checked) to the Unix side, so
that we can use whatever signals we want. This has the added benefit
of eliminating a difference between Unix and Windows.
Re: beta?
Posted by rb...@covalent.net.
> > Nope, -USR1 should have done it. This is a bit annoying, we have to use
> > two different signals, one for threaded versions, one for
> > non-threaded. Prefork uses SIGUSR1 because that's what 1.3
> > did. MPMT_pthread and dexter us SIGWINCH, because that doesn't collide
> > with old versions of Linux.
> >
>
> Oh, god no. Please make them all the same (one or the other, it doesn't
> matter). Otherwise this will just be a nightmare to document, let alone
> use.
Joshua, you are preaching to the choir. If we make them the same, it
needs to be SIGWINCH. I can do that easily enough, but I need more buy-in
before I do.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Joshua Slive <sl...@finance.commerce.ubc.ca>.
On Sat, 27 Jan 2001 rbb@covalent.net wrote:
> Nope, -USR1 should have done it. This is a bit annoying, we have to use
> two different signals, one for threaded versions, one for
> non-threaded. Prefork uses SIGUSR1 because that's what 1.3
> did. MPMT_pthread and dexter us SIGWINCH, because that doesn't collide
> with old versions of Linux.
>
Oh, god no. Please make them all the same (one or the other, it doesn't
matter). Otherwise this will just be a nightmare to document, let alone
use.
Joshua
Re: beta?
Posted by rb...@covalent.net.
> > > That seems like unfortunate logic. How does apachectl know which signal
> > > to send?
> > >
> > > I know it's a change from 1.3, but we should be consistant across MPMs,
> > > doncha thing? So long as this is one of those documented changes, I don't
> > > see the problem.
> >
> > It is unfortunate. I guess that's two people, one more and I am willing
> > to fix this.
>
> +1
Expect a patch tonight then. Thanks for the three quick +1's.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net wrote:
>
> > > Nope, -USR1 should have done it. This is a bit annoying, we have to use
> > > two different signals, one for threaded versions, one for
> > > non-threaded. Prefork uses SIGUSR1 because that's what 1.3
> > > did. MPMT_pthread and dexter us SIGWINCH, because that doesn't collide
> > > with old versions of Linux.
> >
> > That seems like unfortunate logic. How does apachectl know which signal
> > to send?
> >
> > I know it's a change from 1.3, but we should be consistant across MPMs,
> > doncha thing? So long as this is one of those documented changes, I don't
> > see the problem.
>
> It is unfortunate. I guess that's two people, one more and I am willing
> to fix this.
+1
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: beta?
Posted by rb...@covalent.net.
> > Nope, -USR1 should have done it. This is a bit annoying, we have to use
> > two different signals, one for threaded versions, one for
> > non-threaded. Prefork uses SIGUSR1 because that's what 1.3
> > did. MPMT_pthread and dexter us SIGWINCH, because that doesn't collide
> > with old versions of Linux.
>
> That seems like unfortunate logic. How does apachectl know which signal
> to send?
>
> I know it's a change from 1.3, but we should be consistant across MPMs,
> doncha thing? So long as this is one of those documented changes, I don't
> see the problem.
It is unfortunate. I guess that's two people, one more and I am willing
to fix this.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Brian Behlendorf <br...@collab.net>.
On Sat, 27 Jan 2001 rbb@covalent.net wrote:
> Nope, -USR1 should have done it. This is a bit annoying, we have to use
> two different signals, one for threaded versions, one for
> non-threaded. Prefork uses SIGUSR1 because that's what 1.3
> did. MPMT_pthread and dexter us SIGWINCH, because that doesn't collide
> with old versions of Linux.
That seems like unfortunate logic. How does apachectl know which signal
to send?
I know it's a change from 1.3, but we should be consistant across MPMs,
doncha thing? So long as this is one of those documented changes, I don't
see the problem.
Brian
Re: beta?
Posted by rb...@covalent.net.
> > I'd rather spend time finding ways to crash the server than looking
> > into e-mails from regression test machines complaining that they won't
> > build or some test failed.
>
> Have a gander over in /usr/local/apache2/corefiles on apache.org, then -
> so far I've reaped about 100 core files, and they're readable by anyone on
> the system. It's infrequent enough that I've not put 1.3 back up, but
> it's often enough that it's worth looking into.
>
> Also, a kill -WINCH of the server didn't close/reopen the fd's to the
> logfiles when they were rotated last night, nor did a -HUP, only a full
> restart did what it was supposed to. Or is there some other way to do it?
Nope, -USR1 should have done it. This is a bit annoying, we have to use
two different signals, one for threaded versions, one for
non-threaded. Prefork uses SIGUSR1 because that's what 1.3
did. MPMT_pthread and dexter us SIGWINCH, because that doesn't collide
with old versions of Linux.
I'll look at the core files later today.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: beta?
Posted by Brian Behlendorf <br...@collab.net>.
On 27 Jan 2001, Jeff Trawick wrote:
> I'd rather spend time finding ways to crash the server than looking
> into e-mails from regression test machines complaining that they won't
> build or some test failed.
Have a gander over in /usr/local/apache2/corefiles on apache.org, then -
so far I've reaped about 100 core files, and they're readable by anyone on
the system. It's infrequent enough that I've not put 1.3 back up, but
it's often enough that it's worth looking into.
Also, a kill -WINCH of the server didn't close/reopen the fd's to the
logfiles when they were rotated last night, nor did a -HUP, only a full
restart did what it was supposed to. Or is there some other way to do it?
Brian
Re: beta?
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> So, here is what I would ask for. There are a couple of patches still out
> there. Let's do what it takes to commit them over the next week, and in
> the first week of February, the week of 5th, let's shoot for a beta
> release. I would suggest we do it next week, but I believe a lot of us
> will be in NY for LinuxWorld.
Sounds good...
I would like to see us put a brake on unnecessary patches so that
everybody runs mostly the same code for a while and we figure out what
is actually broken. We've broken the build a few times in the last
week, we've introduced new breakage, so extra work has been devoted to
fixing snafus. While that is usually to be expected, it makes it hard
to concentrate on a beta because things are changing so quickly. I'd
rather spend time finding ways to crash the server than looking into
e-mails from regression test machines complaining that they won't
build or some test failed.
For core Apache code and modules such as cgi[d], mime, autoindex,
include, rewrite, etc. (I'm not too concerned with miscellaneous
modules; they may or may not work as it stands anyway) as well as key
bits of APR (most of it), I'd like to see 2 +1s prior to any commit
(other than to fix a compile breakage or some warning that cropped up
on some compiler after a commit). Hopefully this means that if the
change doesn't fix a real problem it won't go in. After beta 1 is
released, we can loosen things up again.
So maybe an API change will happen in b2 instead of b1. I guess I'm
placing a higher value on server stability than API stability.
I don't really like such formalisms, but I'd like to see things slow
down drastically leading up to beta 1.
As always, best wishes to everyone regardless of your opinion :)
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...