Re: [RFC] Change our habits in module naming?

2002-06-18 Thread Per Einar Ellefsen

At 13:22 18.06.2002, Stas Bekman wrote:
[when suggesting things please give people some time to respond, 
especially given the crazy traffic at this list lately. I just had a 
chance to read this thread.]

Sorry.

I'm -1 on renaming. Here is why:

I never talked about renaming. I talked about new modules.

- Not all modules fit into suggested categories, some modules belong to 
several ones.

Of course, but just like on regular CPAN you choose a category even if it 
might not be *exactly* the one you're looking for, it's possible to choose 
a namespace because it's what's most appropriate for a module. If there's 
really a problem, then a new namespace could be created, there's nothing 
wrong with that.

- We definitely don't want the hell to break loose by pushing the authors 
to rename their modules. Think of all the documents which aren't under our 
control which refer to these module names! Books and articles to start with.

As I said, I didn't say we should rename existing modules.

- This is also doesn't help with the move to 2.0, because many modules 
will work with both versions without changes, or with some internal 
changes transparent to users. It doesn't force authors to rename their 
modules. And with the Apache2/ dir trick, there is no reason for doing 
that at all.

The Apache2/ trick doesn't help *people* follow module namings. My proposal 
is mainly targeted at peoples' minds: we like organization, that's why we 
have namespaces in the first place!

It'd be great though to have guidelines for developing Apache:: modules 
and their name conventions. There feel free to suggest a better categorization.

Oops, didn't see this one :) Well, that was mostly my suggestion. It's just 
about the naming for new modules.

And I'm -1 on maintaining a separate catalog. Here is why:

CPAN is already categorizing Apache:: modules.
http://www.cpan.org/modules/00modlist.long.html#ID15_WorldWideW (just 
scroll down till you get to Apache::)
all we need is to add #Apache and the problem solved. We have already 
tried to maintain apache-modlist.html, which just didn't work, the file 
was neglected and many new modules aren't there. Whereas they are in the 
CPAN listing. May be instead of potentially wasting efforts here, the 
effort should go to help improve 00modlist.long.html, so both Apache and 
other Perl categories will benefit from this. I'm quite sure that Andreas 
and folks who bring you CPAN will be glad to get any help in this 
direction. Andreas please correct me if I'm wrong.

That's why I contacted [EMAIL PROTECTED] I feel too that this would belong 
in the Perl module listing (although that didn't appear clearly in my other 
e-mail), but my proposal to PAUSE was just there to allow module authors to 
do their classification.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]





Re: [RFC] Change our habits in module naming?

2002-06-16 Thread Per Einar Ellefsen

At 17:01 16.06.2002, Perrin Harkins wrote:
  I have been thinking about a reorganization of the Apache/Perl modules
for
  a while, and have come to the conclusion that it would probably be a
good
  idea. Please tell me what you think about this proposal.

Sounds fine to me.  I would suggest creating a brief document with
naming guidelines that people can be referred to.

Also, a module map might be a good thing to create, i.e. an improved
version of this: http://perl.apache.org/src/apache-modlist.html.

Well, because the module list has now moved into the Perl Module List 
entirely, we are removing it with the new site. However, I have created a 
new document which takes over that task somewhat, here: 
http://perl.apache.org/release/products/apache-modules.html . That's where 
I was thinking to have the guidelines. As for the organization of the 
module list, I suppose that new modules that adapt these guidelines will be 
correctly organized into the Perl module list (because of their different 
namespaces).


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]





Re: [RFC] Change our habits in module naming?

2002-06-16 Thread Perrin Harkins

 Also, a module map might be a good thing to create, i.e. an improved
 version of this: http://perl.apache.org/src/apache-modlist.html.

 Well, because the module list has now moved into the Perl Module List
 entirely, we are removing it with the new site.

What I meant was that since you can't expect all of the existing modules
to change their names you could make a little directory page that
follows the organization you're proposing and have it list the existing
modules in each category.  Maybe not worth it, but it could be useful
for newbies.

- Perrin




Re: [RFC] Change our habits in module naming?

2002-06-16 Thread Per Einar Ellefsen

At 18:01 16.06.2002, Perrin Harkins wrote:
  Also, a module map might be a good thing to create, i.e. an improved
  version of this: http://perl.apache.org/src/apache-modlist.html.
 
  Well, because the module list has now moved into the Perl Module List
  entirely, we are removing it with the new site.

What I meant was that since you can't expect all of the existing modules
to change their names you could make a little directory page that
follows the organization you're proposing and have it list the existing
modules in each category.  Maybe not worth it, but it could be useful
for newbies.

Yes, I see your point, but my proposal was loosely tied to the categories 
already existing here: 
http://www.cpan.org/modules/00modlist.long.html#ID15_WorldWideW (browse 
down to 'Apache'), so the classification has been done already.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]





RE: [RFC] Change our habits in module naming?

2002-06-16 Thread Randy Kobes

On Sun, 16 Jun 2002, Jonathan M. Hollin wrote:

 I have been thinking about a reorganization of the Apache/Perl modules for
 a while, and have come to the conclusion that it would probably be a good
 idea. Please tell me what you think about this proposal.

 Per Einar, I have cut most your email only for convenience...

 I agree with you.  It would be great (necessary?) to reorganise the mod_perl
 modules on CPAN ready for mod_perl/apache v2.  Users of v1 would also
 benefit from a more descriptive name-space.

 However, the major problem, as I see it is, is simply that people already
 KNOW modules by a specific name and changing them is probably going to lead
 to confusion and possibly even some bitterness.  If I'm setting up a new
 server I'm going to be mighty pissed to have to unlearn what I know about
 the mod_perl module namespace...

 If you think this can be overcome (symbolic links on CPAN anyone?), or if
 you see major support for your proposal, then you also have my vote.  I
 think your idea is sound and logical.  Nice one.

It is a really good suggestion ... The existing modules not
following a naming convention do pose a problem, though, and
possibly future ones who don't/can't follow such a convention for
various reasons (historical, ignorance, multi-purpose, ...).
And then one might get back to having to manually edit the module
list to add these 

To try to automate somewhat the idea of creating Apache
subcategories, and to accommodate existing/future modules, what
about doing something like PAUSE does in how it creates top-level
categories? That is, have a form which presents a list of some
number of subcategories of Apache (eg, some variation of those
Per Einar had: authentication, logging, database, , ), and
the author chooses one (or more) subcategories she/he would like
her/his module to appear in. For each subcategory a number of
subsubcategories are then automatically created, based on the
module name, and the name of the distribution then appears in the
subsubcategory. In this way existing modules can be categorized
without having to change their names (some of which probably
never will, even with modperl-2). As well, it can make allowance
for relevant distributions (eg, Embperl, HTML-Mason, SOAP-Lite)
for which one might not even think to look under an Apache::*
namespace, or those which may fall into one or more
subcategories. Finally, manual editing of the list will be kept
to a minimum, as the author will be able to do most things ...

best regards,
randy kobes