Re: multiple categories

[Peter Simons]

Guido Draheim writes:

 > [...] the macro name does not carry all [...]

That is why I introduced the short description, which authors can use
in case the macro name is not expressive enough. Also, a search engine
would find the keyword in the documentation as well.


 > [...] the macro names have lots of recurring bits that make the
 > table very long in kilobytes

As of now, the macro index page is 18 kilobytes large, and I expect it
to shrink once we went through the current contents. I don't think
that the size of the HTML document is really an issue, given that most
web sites carry megabytes worth of images, while we provide 18
kilobytes of actual content.

Besides, putting macros into multiple categories will make the pages
_larger_, not smaller.


 > let [the browser's full-text search] better work on an index-list
 > that [contains] just the possible keys to search for, pre-ordered
 > in fact to navigate quickly to it, and with an inverted-index of
 > possible matches in the macros.

Uh, don't you think that you're aiming for a bit too much? We're
providing a bunch of Autoconf macros for download ... What you
describe above would probably win us the Librarian's Nobel Prize. I
don't mind making a cool site with advanced technology and all, but
IMHO would should rather spend our time putting good _macros_ into it,
then working on bleeding-edge presentation.

I'd like to reiterate on the lessons learned from the World Wide Web:
_Nobody_ cares about Yahoo these days, no matter how sophisticated
their category system is. Everybody uses a search engine to find
content. If we get a good search engine up and running, we'll have
done more for the users than we possible could by enhancing the
category system.


 > [...] the frontpage of sfnet has gotten too long to my taste [...].
 > I do expect the same thing to happen with the gnu ac-archive in the
 > near future. Since it is not the case _now_, it makes you not have
 > that wish..... yet.

This is obviously a matter of personal taste. I personally do never
break pages up when they logically belong on one page -- just see
<http://cryp.to/> for a somewhat extreme example -- and I have never
ever received a single complaint about this practice.

Let's say that 80 macros (of the 220 we have now) survive the review
process, then this whole problem will be virtually non-existent. And
given the rate of growth the archive had in the past few years, which
will be considerably slower with the new policy, we won't have to
worry about this for next two or three years either!

I agree that putting a lot of effort into this issue is a good thing.
But I doubt it is worthwhile.


 > stdint.h - c support, system headers

Note the descriptions of the either category:

    C Language Support
        Testing capabilities of the C compiler.

    System Headers and Libraries
        Testing properties of the system's header files and libraries.

The c_support category is for _compiler_ properties, not for header
files. <stdint.h> may well be used in C++ and Objective C as well. So
we would have to add it to those categories as well. Even worse, when
a new category would be added, objective_c for instance, we would have
to go through all the current contents and check whether it would
belong there, too, or we introduce inconsistency.


 > java home - installed package, java support
 > cc_for_build - cross compilation, build tool

Arguably these could be added into both categories, but I don't expect
any flames from users if we put them only into the first category you
listed, because that is IMHO where users would look for them.


 > [I wish] to have `recently obsoleted` macros to still be around on
 > topic pages somewhere near the end of the table, plus the sfnet
 > specific thing of experimental and user macros (`under
 > development`), to be also up there.

Wouldn't it suffice to put those macros into the "candidate" category?
Then they are available through the archive's web site, they can
eventually enter the submission procedure, and they will eventually be
included in the release archive.

As for recently obsoleted macros: _Why_ do you want them to be visible
in the main categories? I still cannot see the reason to list a macro
that we know to be _obsolete_. Again, a macro does not become obsolete
for nothing, it becomes obsolete when ...

 (a) it is now part of Autoconf,

 (b) there is now a _better_ one, or

 (c) it is broken.


 > The sfnet branch is shipping an `acinclude` copy of all the m4
 > macros, and it is not a good idea to put them all into _one_
 > directory.

Why not?

As far as I can tell, this is actually necessary for "aclocal" to be
able to find them.

Peter