You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Morgan <rm...@covalent.net> on 2002/10/01 02:35:40 UTC
Re: [PATCH] DAV method registration
I didnt get any feedback on this patch from a couple of weeks ago. See
below for the details.
-Ryan
--
This patch moves all the DAV method registration into the mod_dav module
from the http core. I'd like to do this for a couple reasons:
1) It makes more sense to register these methods from the same module
they are used in.
2) Since Apache can only handle 62 registered methods, it doesn't make
sense to register these in the core even if the dav module isn't loaded.
(Other modules may need these slots in the method bitmask)
This does have the side-effect that method numbers looked up from DAV
will now come from the methods_registry hashtable, rather than the slightly
faster internal method lookup. However, I don't think the performance
difference between the two should be that great.
This patch also fixes a bug where DAV's BIND and SEARCH methods were being
registered with the core twice, since post_config gets called twice.
I have put in a check so that the methods only get registered once.
This passes the DAV litmus test (http://www.webdav.org/neon/litmus/), but
it could use some reviewing by people more familiar the module.
Comments?
-Ryan
Index: include/httpd.h
===================================================================
RCS file: /home/cvspublic/httpd-2.0/include/httpd.h,v
retrieving revision 1.189
diff -u -r1.189 httpd.h
--- include/httpd.h 1 Jul 2002 17:49:53 -0000 1.189
+++ include/httpd.h 19 Sep 2002 04:12:38 -0000
@@ -529,27 +529,9 @@
#define M_DELETE 3
#define M_CONNECT 4
#define M_OPTIONS 5
-#define M_TRACE 6 /* RFC 2616: HTTP */
-#define M_PATCH 7 /* no rfc(!) ### remove this one? */
-#define M_PROPFIND 8 /* RFC 2518: WebDAV */
-#define M_PROPPATCH 9 /* : */
-#define M_MKCOL 10
-#define M_COPY 11
-#define M_MOVE 12
-#define M_LOCK 13
-#define M_UNLOCK 14 /* RFC 2518: WebDAV */
-#define M_VERSION_CONTROL 15 /* RFC 3253: WebDAV Versioning */
-#define M_CHECKOUT 16 /* : */
-#define M_UNCHECKOUT 17
-#define M_CHECKIN 18
-#define M_UPDATE 19
-#define M_LABEL 20
-#define M_REPORT 21
-#define M_MKWORKSPACE 22
-#define M_MKACTIVITY 23
-#define M_BASELINE_CONTROL 24
-#define M_MERGE 25
-#define M_INVALID 26 /* RFC 3253: WebDAV Versioning */
+#define M_TRACE 6
+#define M_PATCH 7 /* RFC 2068: HTTP */
+#define M_INVALID 8 /* For un-implemented commands */
/**
* METHODS needs to be equal to the number of bits
Index: modules/dav/main/mod_dav.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/dav/main/mod_dav.c,v
retrieving revision 1.89
diff -u -r1.89 mod_dav.c
--- modules/dav/main/mod_dav.c 19 Sep 2002 02:36:08 -0000 1.89
+++ modules/dav/main/mod_dav.c 19 Sep 2002 04:12:51 -0000
@@ -137,19 +137,68 @@
enum {
DAV_M_BIND = 0,
DAV_M_SEARCH,
+ DAV_M_PROPFIND,
+ DAV_M_PROPPATCH,
+ DAV_M_MKCOL,
+ DAV_M_COPY,
+ DAV_M_MOVE,
+ DAV_M_LOCK,
+ DAV_M_UNLOCK,
+ DAV_M_VERSION_CONTROL,
+ DAV_M_CHECKOUT,
+ DAV_M_UNCHECKOUT,
+ DAV_M_CHECKIN,
+ DAV_M_UPDATE,
+ DAV_M_LABEL,
+ DAV_M_REPORT,
+ DAV_M_MKWORKSPACE,
+ DAV_M_MKACTIVITY,
+ DAV_M_BASELINE_CONTROL,
+ DAV_M_MERGE,
DAV_M_LAST
};
-static int dav_methods[DAV_M_LAST];
+static int dav_methods[DAV_M_LAST];
static int dav_init_handler(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp,
server_rec *s)
{
/* DBG0("dav_init_handler"); */
+ void *data;
+ const char *dav_init_key = "dav_init_handler";
+
+ /* Only register the methods and add the version component on the
+ * second run of post_config */
+ apr_pool_userdata_get(&data, dav_init_key, s->process->pool);
+ if (!data) {
+ apr_pool_userdata_set((const void *)1, dav_init_key,
+ apr_pool_cleanup_null, s->process->pool);
+ return OK;
+ }
/* Register DAV methods */
dav_methods[DAV_M_BIND] = ap_method_register(p, "BIND");
dav_methods[DAV_M_SEARCH] = ap_method_register(p, "SEARCH");
+ dav_methods[DAV_M_PROPFIND] = ap_method_register(p, "PROPFIND");
+ dav_methods[DAV_M_PROPPATCH] = ap_method_register(p, "PROPPATCH");
+ dav_methods[DAV_M_MKCOL] = ap_method_register(p, "MKCOL");
+ dav_methods[DAV_M_COPY] = ap_method_register(p, "COPY");
+ dav_methods[DAV_M_MOVE] = ap_method_register(p, "MOVE");
+ dav_methods[DAV_M_LOCK] = ap_method_register(p, "LOCK");
+ dav_methods[DAV_M_UNLOCK] = ap_method_register(p, "UNLOCK");
+ dav_methods[DAV_M_VERSION_CONTROL] =
+ ap_method_register(p, "VERSION-CONTROL");
+ dav_methods[DAV_M_CHECKOUT] = ap_method_register(p, "CHECKOUT");
+ dav_methods[DAV_M_UNCHECKOUT] = ap_method_register(p, "UNCHECKOUT");
+ dav_methods[DAV_M_CHECKIN] = ap_method_register(p, "CHECKIN");
+ dav_methods[DAV_M_UPDATE] = ap_method_register(p, "UPDATE");
+ dav_methods[DAV_M_LABEL] = ap_method_register(p, "LABEL");
+ dav_methods[DAV_M_REPORT] = ap_method_register(p, "REPORT");
+ dav_methods[DAV_M_MKWORKSPACE] = ap_method_register(p, "MKWORKSPACE");
+ dav_methods[DAV_M_MKACTIVITY] = ap_method_register(p, "MKACTIVITY");
+ dav_methods[DAV_M_BASELINE_CONTROL] =
+ ap_method_register(p, "BASELINE-CONTROL");
+ dav_methods[DAV_M_MERGE] = ap_method_register(p, "MERGE");
ap_add_version_component(p, "DAV/2");
@@ -4461,13 +4510,13 @@
* These are the DAV methods we handle.
*/
r->allowed |= 0
- | (AP_METHOD_BIT << M_COPY)
- | (AP_METHOD_BIT << M_LOCK)
- | (AP_METHOD_BIT << M_UNLOCK)
- | (AP_METHOD_BIT << M_MKCOL)
- | (AP_METHOD_BIT << M_MOVE)
- | (AP_METHOD_BIT << M_PROPFIND)
- | (AP_METHOD_BIT << M_PROPPATCH);
+ | (AP_METHOD_BIT << dav_methods[DAV_M_COPY])
+ | (AP_METHOD_BIT << dav_methods[DAV_M_LOCK])
+ | (AP_METHOD_BIT << dav_methods[DAV_M_UNLOCK])
+ | (AP_METHOD_BIT << dav_methods[DAV_M_MKCOL])
+ | (AP_METHOD_BIT << dav_methods[DAV_M_MOVE])
+ | (AP_METHOD_BIT << dav_methods[DAV_M_PROPFIND])
+ | (AP_METHOD_BIT << dav_methods[DAV_M_PROPPATCH]);
/*
* These are methods that we don't handle directly, but let the
@@ -4507,75 +4556,75 @@
return dav_method_options(r);
}
- if (r->method_number == M_PROPFIND) {
+ if (r->method_number == dav_methods[DAV_M_PROPFIND]) {
return dav_method_propfind(r);
}
- if (r->method_number == M_PROPPATCH) {
+ if (r->method_number == dav_methods[DAV_M_PROPPATCH]) {
return dav_method_proppatch(r);
}
- if (r->method_number == M_MKCOL) {
+ if (r->method_number == dav_methods[DAV_M_MKCOL]) {
return dav_method_mkcol(r);
}
- if (r->method_number == M_COPY) {
+ if (r->method_number == dav_methods[DAV_M_COPY]) {
return dav_method_copymove(r, DAV_DO_COPY);
}
- if (r->method_number == M_MOVE) {
+ if (r->method_number == dav_methods[DAV_M_MOVE]) {
return dav_method_copymove(r, DAV_DO_MOVE);
}
- if (r->method_number == M_LOCK) {
+ if (r->method_number == dav_methods[DAV_M_LOCK]) {
return dav_method_lock(r);
}
- if (r->method_number == M_UNLOCK) {
+ if (r->method_number == dav_methods[DAV_M_UNLOCK]) {
return dav_method_unlock(r);
}
- if (r->method_number == M_VERSION_CONTROL) {
+ if (r->method_number == dav_methods[DAV_M_VERSION_CONTROL]) {
return dav_method_vsn_control(r);
}
- if (r->method_number == M_CHECKOUT) {
+ if (r->method_number == dav_methods[DAV_M_CHECKOUT]) {
return dav_method_checkout(r);
}
- if (r->method_number == M_UNCHECKOUT) {
+ if (r->method_number == dav_methods[DAV_M_UNCHECKOUT]) {
return dav_method_uncheckout(r);
}
- if (r->method_number == M_CHECKIN) {
+ if (r->method_number == dav_methods[DAV_M_CHECKIN]) {
return dav_method_checkin(r);
}
- if (r->method_number == M_UPDATE) {
+ if (r->method_number == dav_methods[DAV_M_UPDATE]) {
return dav_method_update(r);
}
- if (r->method_number == M_LABEL) {
+ if (r->method_number == dav_methods[DAV_M_LABEL]) {
return dav_method_label(r);
}
- if (r->method_number == M_REPORT) {
+ if (r->method_number == dav_methods[DAV_M_REPORT]) {
return dav_method_report(r);
}
- if (r->method_number == M_MKWORKSPACE) {
+ if (r->method_number == dav_methods[DAV_M_MKWORKSPACE]) {
return dav_method_make_workspace(r);
}
- if (r->method_number == M_MKACTIVITY) {
+ if (r->method_number == dav_methods[DAV_M_MKACTIVITY]) {
return dav_method_make_activity(r);
}
- if (r->method_number == M_BASELINE_CONTROL) {
+ if (r->method_number == dav_methods[DAV_M_BASELINE_CONTROL]) {
return dav_method_baseline_control(r);
}
- if (r->method_number == M_MERGE) {
+ if (r->method_number == dav_methods[DAV_M_MERGE]) {
return dav_method_merge(r);
}
Index: modules/http/http_protocol.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.458
diff -u -r1.458 http_protocol.c
--- modules/http/http_protocol.c 6 Sep 2002 01:27:48 -0000 1.458
+++ modules/http/http_protocol.c 19 Sep 2002 04:13:00 -0000
@@ -454,24 +454,6 @@
register_one_method(p, "OPTIONS", M_OPTIONS);
register_one_method(p, "TRACE", M_TRACE);
register_one_method(p, "PATCH", M_PATCH);
- register_one_method(p, "PROPFIND", M_PROPFIND);
- register_one_method(p, "PROPPATCH", M_PROPPATCH);
- register_one_method(p, "MKCOL", M_MKCOL);
- register_one_method(p, "COPY", M_COPY);
- register_one_method(p, "MOVE", M_MOVE);
- register_one_method(p, "LOCK", M_LOCK);
- register_one_method(p, "UNLOCK", M_UNLOCK);
- register_one_method(p, "VERSION-CONTROL", M_VERSION_CONTROL);
- register_one_method(p, "CHECKOUT", M_CHECKOUT);
- register_one_method(p, "UNCHECKOUT", M_UNCHECKOUT);
- register_one_method(p, "CHECKIN", M_CHECKIN);
- register_one_method(p, "UPDATE", M_UPDATE);
- register_one_method(p, "LABEL", M_LABEL);
- register_one_method(p, "REPORT", M_REPORT);
- register_one_method(p, "MKWORKSPACE", M_MKWORKSPACE);
- register_one_method(p, "MKACTIVITY", M_MKACTIVITY);
- register_one_method(p, "BASELINE-CONTROL", M_BASELINE_CONTROL);
- register_one_method(p, "MERGE", M_MERGE);
}
AP_DECLARE(int) ap_method_register(apr_pool_t *p, const char *methname)
@@ -555,41 +537,14 @@
&& method[2] == 'S'
&& method[3] == 'T'
? M_POST : UNKNOWN_METHOD);
- case 'M':
- return (method[1] == 'O'
- && method[2] == 'V'
- && method[3] == 'E'
- ? M_MOVE : UNKNOWN_METHOD);
- case 'L':
- return (method[1] == 'O'
- && method[2] == 'C'
- && method[3] == 'K'
- ? M_LOCK : UNKNOWN_METHOD);
- case 'C':
- return (method[1] == 'O'
- && method[2] == 'P'
- && method[3] == 'Y'
- ? M_COPY : UNKNOWN_METHOD);
default:
return UNKNOWN_METHOD;
}
case 5:
- switch (method[2])
+ switch (method[0])
{
case 'T':
- return (memcmp(method, "PATCH", 5) == 0
- ? M_PATCH : UNKNOWN_METHOD);
- case 'R':
- return (memcmp(method, "MERGE", 5) == 0
- ? M_MERGE : UNKNOWN_METHOD);
- case 'C':
- return (memcmp(method, "MKCOL", 5) == 0
- ? M_MKCOL : UNKNOWN_METHOD);
- case 'B':
- return (memcmp(method, "LABEL", 5) == 0
- ? M_LABEL : UNKNOWN_METHOD);
- case 'A':
return (memcmp(method, "TRACE", 5) == 0
? M_TRACE : UNKNOWN_METHOD);
default:
@@ -599,21 +554,6 @@
case 6:
switch (method[0])
{
- case 'U':
- switch (method[5])
- {
- case 'K':
- return (memcmp(method, "UNLOCK", 6) == 0
- ? M_UNLOCK : UNKNOWN_METHOD);
- case 'E':
- return (memcmp(method, "UPDATE", 6) == 0
- ? M_UPDATE : UNKNOWN_METHOD);
- default:
- return UNKNOWN_METHOD;
- }
- case 'R':
- return (memcmp(method, "REPORT", 6) == 0
- ? M_REPORT : UNKNOWN_METHOD);
case 'D':
return (memcmp(method, "DELETE", 6) == 0
? M_DELETE : UNKNOWN_METHOD);
@@ -630,54 +570,9 @@
case 'O':
return (memcmp(method, "CONNECT", 7) == 0
? M_CONNECT : UNKNOWN_METHOD);
- case 'H':
- return (memcmp(method, "CHECKIN", 7) == 0
- ? M_CHECKIN : UNKNOWN_METHOD);
- default:
- return UNKNOWN_METHOD;
- }
-
- case 8:
- switch (method[0])
- {
- case 'P':
- return (memcmp(method, "PROPFIND", 8) == 0
- ? M_PROPFIND : UNKNOWN_METHOD);
- case 'C':
- return (memcmp(method, "CHECKOUT", 8) == 0
- ? M_CHECKOUT : UNKNOWN_METHOD);
- default:
- return UNKNOWN_METHOD;
- }
-
- case 9:
- return (memcmp(method, "PROPPATCH", 9) == 0
- ? M_PROPPATCH : UNKNOWN_METHOD);
-
- case 10:
- switch (method[0])
- {
- case 'U':
- return (memcmp(method, "UNCHECKOUT", 10) == 0
- ? M_UNCHECKOUT : UNKNOWN_METHOD);
- case 'M':
- return (memcmp(method, "MKACTIVITY", 10) == 0
- ? M_MKACTIVITY : UNKNOWN_METHOD);
default:
return UNKNOWN_METHOD;
}
-
- case 11:
- return (memcmp(method, "MKWORKSPACE", 11) == 0
- ? M_MKWORKSPACE : UNKNOWN_METHOD);
-
- case 15:
- return (memcmp(method, "VERSION-CONTROL", 15) == 0
- ? M_VERSION_CONTROL : UNKNOWN_METHOD);
-
- case 16:
- return (memcmp(method, "BASELINE-CONTROL", 16) == 0
- ? M_BASELINE_CONTROL : UNKNOWN_METHOD);
default:
return UNKNOWN_METHOD;
Re: [PATCH] DAV method registration
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 30, 2002 at 10:18:14PM -0700, Ryan Morgan wrote:
> On Mon, Sep 30, 2002 at 07:04:49PM -0700, Greg Stein wrote:
> > On Mon, Sep 30, 2002 at 05:35:40PM -0700, Ryan Morgan wrote:
> > >...
> > > This patch moves all the DAV method registration into the mod_dav module
> > > from the http core. I'd like to do this for a couple reasons:
> > >
> > > 1) It makes more sense to register these methods from the same module
> > > they are used in.
> >
> > mod_dav is (currently) an optional module. However, those methods are
> > defined within RFC standards. They apply to everything.
>
> Maybe I don't understand how DAV works, but how do the DAV methods apply
> if the mod_dav module is not loaded?
Other modules could handle those. Nothing gives mod_dav any more right to
them than anybody else :-) (of course, nobody else has felt inclined to
write such an alternative)
> The behavior of the server does not
> change (when mod_dav is not loaded) for requests with those methods.
Actually, it does :-) If the method is known, then it returns 405 (Method
Not Allowed). Otherwise, it returns 501 (Method Not Implemented).
Those methods are defined by an RFC, so we can/should include them in our
server. The server can *know* about them, but just declare that they aren't
allowed on the particular resource.
>...
> > If you're going to have slots, then use them for standard methods. At the
> > moment, those are the DAV methods. If/when we see an explosion of other
> > methods, and the space getting crowded, *then* we can move them.
>
> Since Apache2 has the ability to serve multiple protocols, so the number of
> registered methods can grow quite rapidly. Since the HTTP module cannot
> be removed from the server (without some serious effort.. ask rbb), the next
> best thing is to not register those DAV methods if they will not be used by
> the server.
HTTP methods are not going to be used for non-HTTP protocols, so I don't see
how this applies.
> The ideal solution would be to do away with the allow_methods bitmask
> altogether for something that does not have the 62 method limitation.
> This is also quite difficult, since much of the server relies on this
> being a bitmask.
On this part, I very much agree with you :-)
In general, our allow_methods processing is *very* ill-defined (maybe it is,
but it doesn't feel quite "there" to me; mod_dav interacts with it as well
as it can, but still...). A revamp to simply get it all cleaned up is in
order. When the allow_methods stuff was built, that was long before DAV was
around.
>...
> > > This patch also fixes a bug where DAV's BIND and SEARCH methods were being
> > > registered with the core twice, since post_config gets called twice.
> > > I have put in a check so that the methods only get registered once.
> >
> > Barely a bug. The core returns the same number for the second registration.
>
> True, the function will not register the same method twice, but what about
> the case where mod_dav is the first to register a method? The pool that gets
> passed in (pconf) will get cleared on the second run. On the first call
> this is the pool that will be used to create the method hash. (this is
> the hash used for subsequent calls to ap_method_register)
Um... so? If the pool is cleared, then the hash is cleared, too. Later
registrations will go into the new pool.
There is potentially a bug if the hash is created from a different pool than
the one passed to each method registration. We might want to use
apr_hash_pool() inside the method stuff, rather than using the passed pool.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: [PATCH] DAV method registration
Posted by Sander Striker <st...@apache.org>.
> From: Ryan Morgan [mailto:rmorgan@covalent.net]
> Sent: 01 October 2002 07:18
[...]
> Since Apache2 has the ability to serve multiple protocols, so the number of
> registered methods can grow quite rapidly. Since the HTTP module cannot
> be removed from the server (without some serious effort.. ask rbb), the next
> best thing is to not register those DAV methods if they will not be used by
> the server.
When were talking other protocols, it doesn't really make sense to have the
methods mixed with the http methods. We should focus more on making it
easier to not load the HTTP module than to use a 'bandaid' fix. 62 methods
fills up extremely fast when you are going to handle multiple protocols;
what is going to be the next step when you want to serve yet another protocol?
Sander
Re: [PATCH] DAV method registration
Posted by Ryan Morgan <rm...@covalent.net>.
On Mon, Sep 30, 2002 at 07:04:49PM -0700, Greg Stein wrote:
> On Mon, Sep 30, 2002 at 05:35:40PM -0700, Ryan Morgan wrote:
> >...
> > This patch moves all the DAV method registration into the mod_dav module
> > from the http core. I'd like to do this for a couple reasons:
> >
> > 1) It makes more sense to register these methods from the same module
> > they are used in.
>
> mod_dav is (currently) an optional module. However, those methods are
> defined within RFC standards. They apply to everything.
>
Maybe I don't understand how DAV works, but how do the DAV methods apply
if the mod_dav module is not loaded? The behavior of the server does not
change (when mod_dav is not loaded) for requests with those methods.
> > 2) Since Apache can only handle 62 registered methods, it doesn't make
> > sense to register these in the core even if the dav module isn't loaded.
> > (Other modules may need these slots in the method bitmask)
>
> There are no other HTTP methods in the current RFC universe. No other method
> has a "better" claim to those slots than the DAV methods.
>
> If you're going to have slots, then use them for standard methods. At the
> moment, those are the DAV methods. If/when we see an explosion of other
> methods, and the space getting crowded, *then* we can move them.
>
Since Apache2 has the ability to serve multiple protocols, so the number of
registered methods can grow quite rapidly. Since the HTTP module cannot
be removed from the server (without some serious effort.. ask rbb), the next
best thing is to not register those DAV methods if they will not be used by
the server.
The ideal solution would be to do away with the allow_methods bitmask
altogether for something that does not have the 62 method limitation.
This is also quite difficult, since much of the server relies on this
being a bitmask.
> >...
> > This patch also fixes a bug where DAV's BIND and SEARCH methods were being
> > registered with the core twice, since post_config gets called twice.
> > I have put in a check so that the methods only get registered once.
>
> Barely a bug. The core returns the same number for the second registration.
>
True, the function will not register the same method twice, but what about
the case where mod_dav is the first to register a method? The pool that gets
passed in (pconf) will get cleared on the second run. On the first call
this is the pool that will be used to create the method hash. (this is
the hash used for subsequent calls to ap_method_register)
> > This passes the DAV litmus test (http://www.webdav.org/neon/litmus/), but
> > it could use some reviewing by people more familiar the module.
> >
> > Comments?
>
> I see little purpose for this. The DAV methods, which are defined by RFCs,
> are moving out for some nebulous concept of other "more righteous" methods.
> I just don't follow that reasoning :-)
I somehow felt you would see it this way :) Personally, I don't see the
purpose in registering those methods with the core if they are not intended
to be used within the server. From my testing, the behavior of the server
doesn't change, and it frees up resources that can be used by other modules.
-Ryan
Re: [PATCH] DAV method registration
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 30, 2002 at 05:35:40PM -0700, Ryan Morgan wrote:
>...
> This patch moves all the DAV method registration into the mod_dav module
> from the http core. I'd like to do this for a couple reasons:
>
> 1) It makes more sense to register these methods from the same module
> they are used in.
mod_dav is (currently) an optional module. However, those methods are
defined within RFC standards. They apply to everything.
> 2) Since Apache can only handle 62 registered methods, it doesn't make
> sense to register these in the core even if the dav module isn't loaded.
> (Other modules may need these slots in the method bitmask)
There are no other HTTP methods in the current RFC universe. No other method
has a "better" claim to those slots than the DAV methods.
If you're going to have slots, then use them for standard methods. At the
moment, those are the DAV methods. If/when we see an explosion of other
methods, and the space getting crowded, *then* we can move them.
>...
> This patch also fixes a bug where DAV's BIND and SEARCH methods were being
> registered with the core twice, since post_config gets called twice.
> I have put in a check so that the methods only get registered once.
Barely a bug. The core returns the same number for the second registration.
> This passes the DAV litmus test (http://www.webdav.org/neon/litmus/), but
> it could use some reviewing by people more familiar the module.
>
> Comments?
I see little purpose for this. The DAV methods, which are defined by RFCs,
are moving out for some nebulous concept of other "more righteous" methods.
I just don't follow that reasoning :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/