Rich Morin on packaging, documentation, metadata

I don't necessarily know a lot about automake/configure, but it seems to me everyone wants to replace the existing tools. This makes some sense, but in another sense, they seem to be perfectly good tools that everyone is used to.

Why don't we build a database, that can store all this information that configure, or debian's .deb packaging needs, or BSD's configuration needs, and then have output plugins for each different type of data.

so for isntance, there is a uniform way to put this data IN the DB, then once it's inside the Database, we have different output formats, a browseable repository , say on the web or something, and then these plugins for configure scripts, or automake, or what have you.

just a suggestion. Myabe someday I'll have some time to even play with this idea.

Commando was a Good Idea: think about auto-completion of command- line options complete with an understanding that a particular option must be followed by the name of a file that already exists, for example. But generating the software from the man page isn't too good: better to generate the manual page synopsis from the code, and to have commando ask the software about options, as I think some patches to bash can do.

Rich's ideas about packaging are spot on. David Tilbrook's early work was interesting, but required too much of an idiosyncratic environment for widespread adoption.

The API documentation for my lq-text package (it's in PDF) was generated from SGML comments in the C code for the various libraries involved, and I found that this was an effective way of getting me to keep the documentation up to date.

Scripting languages like Perl and Python push the code boundary: they reduce the number of people excluded from understanding the application, because the code is higher level and easier to read.

Shell scripts take this even further.

This led me to think (in 1984 or so) that the best way to write applications would be a very high level language that was easy to understand, that connected together modules that could be written in a more cryptic language (e.g. Perl), which in turn might call C code.

In this way, the top-level code becomes part of its own documentation, and not in a way (like TeX's Web) that requires the reader to understand the code.

All of this is only necessary because the computer is too stupid to be able to explain the problem well enough (in context), together with the user's needs, that it can't explain how the program is to be used. I don't expect that to change in the near future.

In the meantime, anything that helps to relate documentation, code and configuration is To Be Understood And Encouraged.