Re: Modules

[Hans Hagen <pragma@wxs.nl>]

At 07:30 PM 1/18/2002 +0100, Giuseppe Bilotta wrote:

>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.

much of the functionality built in latex styles is available in the context 
core so there is less need for modules

>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).

as long as you use a proper namespace in you local macros ...

also, you can use the *documented* low level macros in syst-*.tex and 
supp-*.tex

>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.

/third/...

with ... being something meaningful

also, the modules should have t-* names, no m-* or else

hosting is no problem,

>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.

there is the everlasting mail list problem: beginners versus experienced users

now, with respect to comp.tex.whatever, i purposely am not on that list (i 
don't want the overhead, don't want to be dragged into too many 
discussions, etc). I leave it upto other members of the context list to 
support those lists.

and ... filtering is not my strongest point

>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.

hm, i see no problem with using multiple packages along each other -)

you may expect more math in future versions

>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.

right, normally i do my best to provide those hooks asap [and while 
upgrading modules, i add more]

on my agenda is a reimplementation of some modules, after which the context 
core should become relatively stable;

we could of course follow a ghostscript approach, with two versions etc etc

>(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.

what i have in mind is a plug in model, as with the (rather beta) otr 
modules, in that case (given a defined interface) users can pop in own 
code, overload functionality etc. In that case there can be different 
flavors as well as an official kernel

>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.

i know -) and hav esome ideas on that -) -)

>Extensions to TeXUtil should be "registered" so that the .tui file
>can contain hooks to modules in the form
>
>x <id> <data>

it maybe that texexec will control all of this

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------