You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rich Bowen <rb...@rcbowen.com> on 2009/11/12 02:56:01 UTC
Obsolete modules in 2.3
Don't you think that maybe it's time to drop mod_imagemap and
mod_cern_meta?
"there is already a large number of CERN users who can exploit this
module."
Seriously?
--
Rich Bowen
rbowen@rcbowen.com
Re: Obsolete modules in 2.3
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Nov 11, 2009 at 20:56, Rich Bowen <rb...@rcbowen.com> wrote:
> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
> "there is already a large number of CERN users who can exploit this module."
> Seriously?
I say "hell yes".
And my response to a user would be "you want that? fine. it is in
apache 2.2. kthxbai."
Cheers,
-g
Re: Obsolete modules in 2.3
Posted by Nick Kew <ni...@webthing.com>.
On 12 Nov 2009, at 01:56, Rich Bowen wrote:
> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
>
> "there is already a large number of CERN users who can exploit this module."
>
> Seriously?
mod_imagemap is a perfectly good application module, albeit a minority
interest one. I don't think we should drop it unless we finally get around
to implementing a CPAN-style module repository we can offer it from.
But why not put the question to users@ for a more diverse audience?
--
Nick Kew
Re: Obsolete modules in 2.3
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Greg Stein wrote:
>> FWIW I know of one customer who absolutely continues to use mod_imagemap and
>> have no indication they plan to drop it.
>>
>> modules/historical/ might be a good waypoint to eliminating these. Enabling
>> them should emit a warning they are no longer interesting and likely to be
>> dropped from future releases. OTOH perhaps we should keep cern_meta, considering
>> the underlying argument from fans of over-aggressive content-type sniffing always
>> cite broken httpd configs as the reason for their sillyness.
>
> Bah. If they want them, then they should not upgrade their server.
> Simple as that.
w.r.t. imagemap, fine, they can build this out-of-tree. w.r.t. cern_meta, I'm just
not seeing the logic behind removing it, any more or less than mime_magic.
Re: Obsolete modules in 2.3
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
Gregg L. Smith schrieb:
> Lars Eilebrecht wrote:
>> Or just use the 2.2 modules with 2.4.
>
> It was just my recent findings with 2.3.3-alpha that this will not work.
> If the APR 1.4(?) that was in httpd-2.3.3-alpha-deps.tar.gz is anything
> close to what will be shipped with 2.4 then no, this may not work. I had
> to rebuild all my 3rd party modules against this version to get them to
> run.
>
> with mod_imagemap 2.2.14
> ------------------------------------------------------------------------
> httpd: Syntax error on line 99 of /Apache23/conf/httpd.conf: Cannot load
> /Apache23/modules/mod_imagemap.so into server: The specified procedure
> could not be found.
> ------------------------------------------------------------------------
>
> To me the easiest solution to gauge the use of these module is to simply
> accidentally (on purpose) remove them from 2.2.15 and see how many
> people complain. If no one does, it can then be deemed safe to remove,
> if you get flooded with complaints, then you will know maybe one or both
> should not be. Personally, I use neither of them.
>
> Just my thoughts,
> Gregg
I have now read all the discussion about this, but still I have not got
the sense behind removing these modules at all. What is so bad with
keeping them in the sources? Why do you all care that much for removing
two modules which were not modified for years, so make practically zero
work with maintainance? It cant be the 5kb compressed size of them, or?
Gün.
Re: Obsolete modules in 2.3
Posted by "Gregg L. Smith" <li...@glewis.com>.
Lars Eilebrecht wrote:
> Or just use the 2.2 modules with 2.4.
It was just my recent findings with 2.3.3-alpha that this will not work.
If the APR 1.4(?) that was in httpd-2.3.3-alpha-deps.tar.gz is anything
close to what will be shipped with 2.4 then no, this may not work. I had
to rebuild all my 3rd party modules against this version to get them to run.
with mod_imagemap 2.2.14
------------------------------------------------------------------------
httpd: Syntax error on line 99 of /Apache23/conf/httpd.conf: Cannot load
/Apache23/modules/mod_imagemap.so into server: The specified procedure
could not be found.
------------------------------------------------------------------------
To me the easiest solution to gauge the use of these module is to simply
accidentally (on purpose) remove them from 2.2.15 and see how many
people complain. If no one does, it can then be deemed safe to remove,
if you get flooded with complaints, then you will know maybe one or both
should not be. Personally, I use neither of them.
Just my thoughts,
Gregg
Re: Obsolete modules in 2.3
Posted by Lars Eilebrecht <la...@apache.org>.
Greg Stein wrote on 2009-11-11 23:33:35:
> Bah. If they want them, then they should not upgrade their server.
> Simple as that.
Or just use the 2.2 modules with 2.4.
There may still be some legacy sites using mod_imagemap or
mod_cern_meta, but in my opinion there is absolutely no reason to
continue including the modules in the httpd package.
+1 on removing mod_imagemap and mod_cern_meta.
ciao...
--
Lars Eilebrecht
lars@apache.org
Re: Obsolete modules in 2.3
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Nov 11, 2009 at 23:21, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Rich Bowen wrote:
>> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
>>
>> "there is already a large number of CERN users who can exploit this module."
>>
>> Seriously?
>
> LOL
>
> FWIW I know of one customer who absolutely continues to use mod_imagemap and
> have no indication they plan to drop it.
>
> modules/historical/ might be a good waypoint to eliminating these. Enabling
> them should emit a warning they are no longer interesting and likely to be
> dropped from future releases. OTOH perhaps we should keep cern_meta, considering
> the underlying argument from fans of over-aggressive content-type sniffing always
> cite broken httpd configs as the reason for their sillyness.
>
Bah. If they want them, then they should not upgrade their server.
Simple as that.
Cheers,
-g
Re: Obsolete modules in 2.3
Posted by Rich Bowen <rb...@rcbowen.com>.
On Nov 17, 2009, at 21:49 , William A. Rowe Jr. wrote:
> Roy T. Fielding wrote:
>> I personally find it useful to continue having support for
>> features that were once used in the past, specifically to
>> test things that once worked to see if they still work
>> with the current version of Apache. Therefore, I do not
>> consider these modules to be obsolete. Unless they are
>> somehow broken right now or preventing us from doing some
>> big change to the architecture, then -1 to removing them.
>>
>> They should not be compiled by default, of course.
>
> I'd be +1 for moving both from modules=most to modules=all. They
> certainly
> don't eat a lot of space and are historically if not currently
> interesting.
Ok. I defer and withdraw my request. Having them not included in
modules=most would be great. Thanks.
--
Rich Bowen
rbowen@rcbowen.com
Re: Obsolete modules in 2.3
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
> I personally find it useful to continue having support for
> features that were once used in the past, specifically to
> test things that once worked to see if they still work
> with the current version of Apache. Therefore, I do not
> consider these modules to be obsolete. Unless they are
> somehow broken right now or preventing us from doing some
> big change to the architecture, then -1 to removing them.
>
> They should not be compiled by default, of course.
I'd be +1 for moving both from modules=most to modules=all. They certainly
don't eat a lot of space and are historically if not currently interesting.
I'd still like to see cern_meta renamed to something that suggests that it
*really does solve* the pain of many CMS/FTP hosted content authors. Even
installing it by default might be a reasonable idea for a typical mass
vhosting configuration.
Re: Obsolete modules in 2.3
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
I personally find it useful to continue having support for
features that were once used in the past, specifically to
test things that once worked to see if they still work
with the current version of Apache. Therefore, I do not
consider these modules to be obsolete. Unless they are
somehow broken right now or preventing us from doing some
big change to the architecture, then -1 to removing them.
They should not be compiled by default, of course.
....Roy
Re: Obsolete modules in 2.3
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Rich Bowen wrote:
>
> As for mod_cern_meta, if one insists on keeping it, perhaps rename it to
> something less archaic, and perhaps merging it with mod_asis to produce
> something actually useful. But, truly, finding people who have even
> *heard* of the CERN web server is getting harder, and providing backward
> compat with it is simply laughable.
mod_mime_metafile or something sensible like that?
Re: Obsolete modules in 2.3
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Nov 12, 2009 at 11:27, Rich Bowen <rb...@rcbowen.com> wrote:
>
> On Nov 12, 2009, at 11:12 , Nick Kew wrote:
>
>> Ken Dreyer wrote:
>>>
>>> (another user's perspective)
>>> At my work (US. Geological Survey) we try to discourage webmasters
>>> from using server-side imagemaps, since they are not Section 508
>>> compliant. We've had to keep the module to support some legacy sites,
>>> but if 2.4 drops it, we can probably migrate any remaining server-side
>>> maps.
>>
>> Hmmm. When I worked alongside some of your folks (joint project -
>> I was at ESRIN) we used server-side imagemaps to let users select
>> points on a (geographical) map. Any user without the map could
>> enter lat/long manually instead, and any clientside solution
>> (like scripting, or embedded java/flash) would raise more
>> serious accessibility problems (you'd want the serverside map
>> as a fallback for accessibility)!
>
> Client-side image maps have been part of HTML for more than a decade. It
> does not require any kind of scripting, java, flash, or javascript.
> If the map can be encoded in a way that mod_imagemap understands, you simply
> take that map data and put it directly in the HTML. The format is the same.
> If the map is complex enough that you can't encode it in a simple text map
> file, then mod_imagemap wouldn't help anyways, and you'd need a custom
> solution. Forcing a round-trip to the server, rather than putting the map
> data in the HTML, doesn't make any sense. mod_imagemap doesn't offer *any*
> features that aren't included in the HTML implementation. Even Lynx supports
> client-side imagemaps. And client-side imagemaps are completely accessible,
> if you do the map right, with comments. Lynx even provides a menu of the
> options in the imagemap, along with their titles/comments.
Just torch it. No need to discuss.
-g
Re: Obsolete modules in 2.3
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Rich Bowen wrote:
>
> On Nov 12, 2009, at 19:09 , Nick Kew wrote:
>
>> Rich Bowen wrote:
>>
>>> Client-side image maps have been part of HTML for more than a decade.
>>
>> Irrelevant for geographic maps - unless you define a different
>> "area" for every pixel!
>>
>> Clientside maps only work with areas, which are generally associated
>> with visual crap rather than anything functional like a point on a map.
>> Altogether different class of application.
>
> Sure, but in that case you wouldn't use mod_imagemap, which also
> requires that you define areas:
> http://httpd.apache.org/docs/2.2/mod/mod_imagemap.html#imapfile
Agreed. The only remaining concern is how is one going to embed easter eggs
in a map now, without revealing the source ;-?
I think the discussion has gone 'round sufficiently to svn rm this from trunk.
Re: Obsolete modules in 2.3
Posted by Rich Bowen <rb...@rcbowen.com>.
On Nov 12, 2009, at 19:09 , Nick Kew wrote:
> Rich Bowen wrote:
>
>> Client-side image maps have been part of HTML for more than a decade.
>
> Irrelevant for geographic maps - unless you define a different
> "area" for every pixel!
>
> Clientside maps only work with areas, which are generally associated
> with visual crap rather than anything functional like a point on a
> map.
> Altogether different class of application.
Sure, but in that case you wouldn't use mod_imagemap, which also
requires that you define areas: http://httpd.apache.org/docs/2.2/mod/mod_imagemap.html#imapfile
--
Rich Bowen
rbowen@rcbowen.com
Re: Obsolete modules in 2.3
Posted by Nick Kew <ni...@webthing.com>.
Rich Bowen wrote:
> Client-side image maps have been part of HTML for more than a decade.
Irrelevant for geographic maps - unless you define a different
"area" for every pixel!
Clientside maps only work with areas, which are generally associated
with visual crap rather than anything functional like a point on a map.
Altogether different class of application.
--
Nick Kew
Re: Obsolete modules in 2.3
Posted by Rich Bowen <rb...@rcbowen.com>.
On Nov 12, 2009, at 11:12 , Nick Kew wrote:
> Ken Dreyer wrote:
>> (another user's perspective)
>> At my work (US. Geological Survey) we try to discourage webmasters
>> from using server-side imagemaps, since they are not Section 508
>> compliant. We've had to keep the module to support some legacy sites,
>> but if 2.4 drops it, we can probably migrate any remaining server-
>> side
>> maps.
>
> Hmmm. When I worked alongside some of your folks (joint project -
> I was at ESRIN) we used server-side imagemaps to let users select
> points on a (geographical) map. Any user without the map could
> enter lat/long manually instead, and any clientside solution
> (like scripting, or embedded java/flash) would raise more
> serious accessibility problems (you'd want the serverside map
> as a fallback for accessibility)!
Client-side image maps have been part of HTML for more than a decade.
It does not require any kind of scripting, java, flash, or javascript.
If the map can be encoded in a way that mod_imagemap understands, you
simply take that map data and put it directly in the HTML. The format
is the same. If the map is complex enough that you can't encode it in
a simple text map file, then mod_imagemap wouldn't help anyways, and
you'd need a custom solution. Forcing a round-trip to the server,
rather than putting the map data in the HTML, doesn't make any sense.
mod_imagemap doesn't offer *any* features that aren't included in the
HTML implementation. Even Lynx supports client-side imagemaps. And
client-side imagemaps are completely accessible, if you do the map
right, with comments. Lynx even provides a menu of the options in the
imagemap, along with their titles/comments.
--
Rich Bowen
rbowen@rcbowen.com
Re: Obsolete modules in 2.3
Posted by Ken Dreyer <kt...@ktdreyer.com>.
On Thu, Nov 12, 2009 at 9:12 AM, Nick Kew <ni...@webthing.com> wrote:
>
> OTOH, that used CERN HTTPD with CGI, not mod_imagemap.
Wow, old school :)
> Don't you have that kind of application any more?
We definitely have a lot of interactive maps, but the processing you
describe is usually handled by CGI or Java. Our only use of
mod_imagemap that I have seen was for a website's navigation bar.
On Thu, Nov 12, 2009 at 9:27 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> Client-side image maps have been part of HTML for more than a decade. It
> does not require any kind of scripting, java, flash, or javascript.
Indeed, and client-side imagemaps are what we recommend to our
webmasters to replace mod_imagemap (as do the Section 508 guidelines).
On Thu, Nov 12, 2009 at 9:30 AM, Greg Stein <gs...@gmail.com> wrote:
>
> Just torch it. No need to discuss.
Strike the match, as far as I'm concerned!
Re: Obsolete modules in 2.3
Posted by Nick Kew <ni...@webthing.com>.
Ken Dreyer wrote:
> (another user's perspective)
>
> At my work (US. Geological Survey) we try to discourage webmasters
> from using server-side imagemaps, since they are not Section 508
> compliant. We've had to keep the module to support some legacy sites,
> but if 2.4 drops it, we can probably migrate any remaining server-side
> maps.
Hmmm. When I worked alongside some of your folks (joint project -
I was at ESRIN) we used server-side imagemaps to let users select
points on a (geographical) map. Any user without the map could
enter lat/long manually instead, and any clientside solution
(like scripting, or embedded java/flash) would raise more
serious accessibility problems (you'd want the serverside map
as a fallback for accessibility)!
OTOH, that used CERN HTTPD with CGI, not mod_imagemap.
Don't you have that kind of application any more?
--
Nick Kew
Re: Obsolete modules in 2.3
Posted by Ken Dreyer <kt...@ktdreyer.com>.
(another user's perspective)
At my work (US. Geological Survey) we try to discourage webmasters
from using server-side imagemaps, since they are not Section 508
compliant. We've had to keep the module to support some legacy sites,
but if 2.4 drops it, we can probably migrate any remaining server-side
maps.
- Ken
On Thu, Nov 12, 2009 at 7:29 AM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>
>> As a non-scientific data point, I have never encountered anybody who knows
>> what mod_imagemap does, in all the years that I've been doing Apache
>> training. And in the 2.0-and-before days, when I would mention mod_imap, the
>> response would ALWAYS be "Apache does IMAP? Really?" Also, I have asked on
>> users@ who uses it, and received one response so far, saying that they
>> hadn't heard of it until my question, and had to go look it up.
>
> Aside from CVE queries, haven't heard a peep in years on IRC/users@ or
> even at $bigco.
>
> Maybe it's just our best, most well-documented module though :)
>
> --
> Eric Covener
> covener@gmail.com
>
Re: Obsolete modules in 2.3
Posted by Sander Temme <sc...@apache.org>.
On Nov 12, 2009, at 8:13 AM, Niklas Edmundsson wrote:
> So drop the confusing example module instead? Or has it been fixed
> lately? ;)
mod_example is now mod_example_hooks and aims to implement a handler
for every hook in the server. It should no longer have the threading
issues previously ascribed to it. There is a mod_example_ipc that
shows how to use shared memory and mutexes. I thought I'd put in a
very skinny mod_example that would be similar to (or the same as) what
apxs -g produces, but I don't see that in trunk and forget what if
anything was discussed about it.
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Obsolete modules in 2.3
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Thu, 12 Nov 2009, Eric Covener wrote:
> On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen <rb...@rcbowen.com> wrote:
>
>> As a non-scientific data point, I have never encountered anybody who knows
>> what mod_imagemap does, in all the years that I've been doing Apache
>> training. And in the 2.0-and-before days, when I would mention mod_imap, the
>> response would ALWAYS be "Apache does IMAP? Really?" Also, I have asked on
>> users@ who uses it, and received one response so far, saying that they
>> hadn't heard of it until my question, and had to go look it up.
>
> Aside from CVE queries, haven't heard a peep in years on IRC/users@ or
> even at $bigco.
>
> Maybe it's just our best, most well-documented module though :)
So drop the confusing example module instead? Or has it been fixed
lately? ;)
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
It's as bad as you think and they are out to get you.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Obsolete modules in 2.3
Posted by Eric Covener <co...@gmail.com>.
On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen <rb...@rcbowen.com> wrote:
> As a non-scientific data point, I have never encountered anybody who knows
> what mod_imagemap does, in all the years that I've been doing Apache
> training. And in the 2.0-and-before days, when I would mention mod_imap, the
> response would ALWAYS be "Apache does IMAP? Really?" Also, I have asked on
> users@ who uses it, and received one response so far, saying that they
> hadn't heard of it until my question, and had to go look it up.
Aside from CVE queries, haven't heard a peep in years on IRC/users@ or
even at $bigco.
Maybe it's just our best, most well-documented module though :)
--
Eric Covener
covener@gmail.com
Re: Obsolete modules in 2.3
Posted by Rich Bowen <rb...@rcbowen.com>.
On Nov 11, 2009, at 23:21 , William A. Rowe Jr. wrote:
> Rich Bowen wrote:
>> Don't you think that maybe it's time to drop mod_imagemap and
>> mod_cern_meta?
>>
>> "there is already a large number of CERN users who can exploit this
>> module."
>>
>> Seriously?
>
> LOL
>
> FWIW I know of one customer who absolutely continues to use
> mod_imagemap and
> have no indication they plan to drop it.
>
> modules/historical/ might be a good waypoint to eliminating these.
> Enabling
> them should emit a warning they are no longer interesting and likely
> to be
> dropped from future releases. OTOH perhaps we should keep
> cern_meta, considering
> the underlying argument from fans of over-aggressive content-type
> sniffing always
> cite broken httpd configs as the reason for their sillyness.
As a non-scientific data point, I have never encountered anybody who
knows what mod_imagemap does, in all the years that I've been doing
Apache training. And in the 2.0-and-before days, when I would mention
mod_imap, the response would ALWAYS be "Apache does IMAP? Really?"
Also, I have asked on users@ who uses it, and received one response so
far, saying that they hadn't heard of it until my question, and had to
go look it up.
Anyone who is using SERVER-SIDE image maps needs to upgrade to
Netscape version 1.4 or later (circa 1992), which does client-side
image maps. Bill, seriously, you need to tell your customer that HTML
2 added support for client-side image maps. It's 2009 now.
As for mod_cern_meta, if one insists on keeping it, perhaps rename it
to something less archaic, and perhaps merging it with mod_asis to
produce something actually useful. But, truly, finding people who have
even *heard* of the CERN web server is getting harder, and providing
backward compat with it is simply laughable.
--
Rich Bowen
rbowen@rcbowen.com
Re: Obsolete modules in 2.3
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Rich Bowen wrote:
> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
>
> "there is already a large number of CERN users who can exploit this module."
>
> Seriously?
LOL
FWIW I know of one customer who absolutely continues to use mod_imagemap and
have no indication they plan to drop it.
modules/historical/ might be a good waypoint to eliminating these. Enabling
them should emit a warning they are no longer interesting and likely to be
dropped from future releases. OTOH perhaps we should keep cern_meta, considering
the underlying argument from fans of over-aggressive content-type sniffing always
cite broken httpd configs as the reason for their sillyness.