Obsolete modules in 2.3

[Rich Bowen]

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@...

[Nick Kew]

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

[Greg Stein-4]

On Wed, Nov 11, 2009 at 20:56, Rich Bowen <rbowen@...> 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

[William A. Rowe Jr.]

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.

[Greg Stein-4]

On Wed, Nov 11, 2009 at 23:21, William A. Rowe Jr. <wrowe@...> 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

[William A. Rowe Jr.]

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.

[Rich Bowen]

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@...

[Eric Covener]

On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen <rbowen@...> 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@...

[Ken Dreyer-2]

(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 <covener@...> wrote:

> On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen <rbowen@...> 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@...
>

[Nick Kew]

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

[Niklas Edmundsson-2]

On Thu, 12 Nov 2009, Eric Covener wrote:

> On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen <rbowen@...> 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@...
---------------------------------------------------------------------------
  It's as bad as you think and they are out to get you.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[Rich Bowen]

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@...

[Greg Stein-4]

On Thu, Nov 12, 2009 at 11:27, Rich Bowen <rbowen@...> 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

[Ken Dreyer-2]

On Thu, Nov 12, 2009 at 9:12 AM, Nick Kew <nick@...> 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 <rbowen@...> 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 <gstein@...> wrote:
>
> Just torch it. No need to discuss.

Strike the match, as far as I'm concerned!

[William A. Rowe Jr.]

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?

[Nick Kew]

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

[Rich Bowen]

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@...

[William A. Rowe Jr.]

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.

[Sander Temme-2]

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@...
PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

[Lars Eilebrecht]

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@...