Re: Modules

[Giuseppe Bilotta <bourbaki@bigfoot.com>]

Thursday, January 17, 2002 Marco Kuhlmann wrote:

MK> However, I wonder if not ConTeXt needs some of that LaTeX
MK> feeling. In LaTeX, when you miss a feature, you know that there
MK> is a package out there that implements it. In ConTeXt, you ask
MK> Hans et al. Why are there so few modules?

MK> It may of course be due to the relatively small number of
MK> users.

I think this is the main reason.

MK> However, one important reason in my opinion is the lack
MK> of a well-defined module interface. How should modules be
MK> designed? Is there a standard library of functions that they
MK> could or should use?

I use pre-existent core and add-on modules to get the ideas for
mine. Much of my knowledge of ConTeXt internal comes from studying
the sources (of course, if Hans used English instead of Dutch, it
would ease my work a lot ;-> but he's working along this path).

MK> If I wrote a new module, how would I
MK> distribute it (for LaTeX, I would use CTAN)?

I suppose you could put it on CTAN as well. Maybe CTAN should have
a /third-party/<contributor name> set of directories under the
context branch. And of course you could ask Hans to host it.

MK> What I propose it that we should think about going public.
MK> ConTeXt has so much to offer, it should become more widely
MK> used. A promising way to achieve this is to get more and more
MK> people involved in enhancing and documenting it.

How would you propose to do this? I've seen some new people
posting about ConTeXt in the comp.text.tex newsgroup, but most
ConTeXt question are put here (which sort of excludes us from the
rest of the TeX community). Maybe Hans and the other experts could
monitor those newsgroup, filtering out all messages which don't
contain ConTeXt in the subject.

Yet for ConTeXt to become widely used it would need to be at least
on par with LaTeX, which it is currently not (e.g. I have to stick
to LaTeX when doing heavy mathematics): when people would have to choose
between ConTeXt and LaTeX they would go for the one which would
present them less problems. ConTeXt has some very strong points,
but they may not be the ones seeked by the users.

MK> That does not
MK> say, of course, that base ConTeXt could and should not remain
MK> in the hands of PRAGMA. But an active community of developers
MK> working on extensions to the core is a good thing. And if it is
MK> well organised, it does not have to threaten the integrity of
MK> the system as a whole.

There are two things I don't like about the LaTeX packages:

(1) their clashing with each other: this usually happens when two
packages change the same LaTeX internal (LaTeX internals often
don't offer hooks to the developers, which is pretty strange IMO
considering how many LaTeX 'extenders' are there).

We can prevent this in ConTeXt by requiring that no public module
hacks any core command: if someone needs to extend a core command,
he should ask Hans to provide a hook for the extensions.

(2) different packages achieving the same result in different
ways: this is harder to deal with because the LaTeX situation
comes from the fact that different people have different ideas on
what should be achieved and why.

We should then require that if an existing module with the same
functionality is already provided, no new module should be
implemented: if someone desires to change something, (s)he would
provide a patch to the original module. Or something of the sort.

Of course this would only hold for "public" modules.

Another thing developers would need is a module interface to
TeXUtil: when a ConTeXt module requires some particular
postprocessing, it should provide a Perl module to be loaded by
TeXUtil.

Extensions to TeXUtil should be "registered" so that the .tui file
can contain hooks to modules in the form

x <id> <data>

where x stands for extension and <id> is a code registered by a
module. TeXUtil would then call whatever appropriate routine is
defined in the module hooking on extension <id> and pass <data> as
the parameters.

This is needed for example by a module of mine (x-desc), but could
be needed by the bibliography module if we want to get rid of the
bibtex executable (we could reimplement bibtex in Perl in a module
called m-bib.pl so that when someone uses Taco's m-bib.tex module
TeXUtil would also load the Perl bib module to deal with the
bibliography data.)

--
Giuseppe "Oblomov" Bilotta