httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <rum...@cord.dk>
Subject [Discuss] Time to rewrite/rethink modules.apache.org?
Date Sat, 19 Jan 2013 23:26:24 GMT
Hello dear dev@,

I'd like to propose that we rewrite and rethink modules.apache.org.
For those of you who detest long emails (henceforth known as the
TL;DRs), just scroll to the bottom for a quick summary.

While modules.a.o does provide a mediocre service to those looking for a
module, I'd like to think we can do a lot better. I've split this into
topics, in which I'll go through each aspect of what I find needs
improvement, and which benefits could come from this, as well as some
more proactive reasons as to why we should rewrite/rethink this site:

---------------------
General look and feel
---------------------
The first thing that strikes me about modules.a.o is that it's not so
much an index, but more like a hastily thrown together list of modules.
It offers no detailed insight into each module, and clicking on either a
module or the browse link takes you to a search function, which at first
makes you think you may have clicked the wrong link or that the site is
broken. The browse feature has no categories or ways to actually index
modules other than listing them alphabetically, which makes searching
quite tedious. I have to use the search feature in my browser if I am to
find for instance a GPL licensed module which deals with security.

Browsing and searching is virtually the same, as in there is no
difference between clicking the browse button or clicking the search
button and searching for an empty string. This gives me the impression
that the search/browse feature has never really been thought through.


----------------
Out-of-datedness
----------------
The site clearly shows signs of not having been updated in over a
decade. You have the option between a 1.3.x or 2.x module - where is the
distinction between 2.0, 2.2, 2.4 and trunk? Some modules have not been
updated since 1998, yet they are still on the list? Surely, there should
be some sort of limit on how many _decades_ your module can remain on
that list without being updated. This should be an index of modules you
can still use, not modules that only works in 1.3.

---------------------
Indexing and browsing
---------------------
Indexing...what indexing, there is none. Everything is just
alphabetical, or you can search for something (the search page doesn't
say what field you're searching?). There are no categories, no ways to
limit your search other than specifying a very specific string (which
probably won't match), no sorting by relevance, popularity, stability,
how up-to-date the module is, etc.

There is no way to limit a search to specific license - I'd like to be
able to just view ASLv2 licensed modules, but I can't.


----------
Moderation
----------
The criteria for having a module listed is nowhere to be found. The
approval process is a mystery (supposedly we have two people working on
this, who may or may not have the time), there is no way to see if your
module has been approved or rejected (as a personal experience with it,
I have yet to find out if the modules I submitted last year were
rejected or just mothballed for all eternity), there seems to be no
reminders sent out if an approval request is not handled.

Requiring a special "task force" seems like not-so-much the Apache Way.
I'd like to see that we can collaborate as committers on this, much like
we do on the comments system, where anyone within the ASF with an
interest in helping out can do so, and where the procedures are both
publicly described and logged in a manner that enables others to see if
something requires attention.


------------
"What's hip"
------------
I'd like to see popular modules included as well - there is no mention
of mod_php, mod_spdy, mod_pagespeed, mod_wsgi and so on, yet these are
probably the modules that people are most inclined to go search for.
While it's generally a good idea to let module authors contribute with
their own modules to the list, I'd also like for this to be a place
where you can find out more information about a particular module, even
if it's a popular one with a corporation or foundation backing it.

I'd also very much like the ability for people to either rate or in some
way discuss modules; How they work, what could be improved, how to set
them up and so on - some form of forum integration where a module can be
put up for debate. I'd also like both users and/or authors to be able to
rate their modules in terms of stability, usefulness (general purpose or
niche product), popularity (how widespread is the use of this module?)
and so forth. This could help people in need of a "cookie cutter" web
server, as they could simply go to the site, view what's the most
popular and used modules, see if/how they work, and find out where to
get them.



-----------------------------------------
Collaborating and eating our own dog food
-----------------------------------------
Now comes the part where some (those that know me well) will chuckle,
some will go "pfeh!", while others may actually think this is a good idea:

I'd like to propose - if people are in favour of this idea - that we do
three big changes:

1) I'd like to scrap all existing data. Out with it! Information that
has not been updated since 1998 does not belong on a site that is
supposed to reflect what's currently available, and the current database
has way too few fields to actually make the information useful to
visitors. If people care about their modules, I'm sure they'd be happy
to resubmit it with a more detailed description, and for the more
popular ones, I'm sure we have a committer or two, who can fill out the
blanks on those.

2) I'd like to propose that we develop a new site using httpd 2.4/2.5
and mod_lua (from trunk - yes, this is where the chuckles and pfehs may
commence) as the scripting engine. We need ways to showcase this module,
and using it ourselves it the perfect way to do so. I know some of you
have expressed interest in getting to know the module a bit better, and
this would be a perfect opportunity to do so. With it we have not only a
way to show many of the ways it can be used, but also a fully flexible,
fast, efficient language with all the fixings needed to operate a
dynamic, vibrant site, just like we do with comments.apache.org.

3) I'd like to propose that this rewrite/rethink becomes a collaboration
between more than just me and my shadow. I'd be happy to do most of the
grunt work, but I'd really love it if others (you know who you are!)
would help out, especially in the overall principles of how such a site
would come together. This would not only be the chance to make something
great, but also a chance to learn a bit about whichever language we
decide on in the end. This collaboration could be done over subversion,
and meetings/discussions could either be via email, or on IRC (we have a
new fancy secretary function, courtesy of wilderness.apache.org).

I could go on, but then I suspect those of you who are not yet inclined
to go TL;DR would do so - I hope you understand the points I'm trying to
make here.

So, to summarize:

- modules.apache.org needs a general overhaul and a more detailed,
dynamic approach to its way of handling/relaying information.
- I propose we rebuild it from scratch, possibly using mod_lua as the
driving engine, to showcase some of its uses.
- I propose that we scrap the old data and start anew with modules that
are still usable for httpd 2.2 and above.
- I propose that this be a collaboration between those who express an
interest in being part of it.
- I propose that moderation/approval on the site be a joint venture
between all committers who themselves have already shown merit to join
the ASF.

Questions, remarks, comments (whether they be snide or not), ideas and,
most important, feedback, is most welcome on this topic!

If the feedback is generally positive and in favour of a
rethink/rebuild, I will propose a vote later this month, and then we'll
take it from there.

With regards,
Daniel.

Mime
View raw message