References: <514443C4.1080503@morningstar2.co.uk>
            <20130316121332.GA5586@csmvddesktop>
            <51458BC2.6060701@latex-project.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Message-ID:  <20130317102834.GB6929@csmvddesktop>
Date:         Sun, 17 Mar 2013 10:28:34 +0000
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: dongen <dongen@CS.UCC.IE>
Subject: Re: Prefix database
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <51458BC2.6060701@latex-project.org>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

* Frank Mittelbach <frank.mittelbach@latex-project.org> [2013-03-17 10:24:18 +0100]:

Hi Frank,

: your suggestion moves the workload to the CTAN team and I don't
: think this is possible or sensible. If at all it needs to be a
: solution that would do the register update fully automatically.

I agree this moves workload to CTAN. There may be other ways
to do this.

: for that reason I don't think that the introduction of another aux
: type file is warranted it would be something only needed for
: managing the register but required all over the place. In contrast,
: if you just have a formal specification, you could regularly build
: the register by scanning across all dtx ctan files.

Yes. That's another possible way. I think the main question is
``Who wants to be the prefix database manager?''

: >You can even make the kernel method reject existing prefixes. (Of course
: >this would mean the method needs some way to access a local copy of the
: >prefix database....) This may save the programmer precious time and
: >troubles.
: 
: I don't think we want to reject prefixes. We encourage not to use
: existing ones, but there will be a time when this is needed and
: wanted. And in some cases reuse to "extend" a code base will also
: come into play. And how would you want to communicated with a
: developer? if you issue a warning then if it is deliberate you will
: need a way to get rid of it and such a warning should not show up
: (imho) for a normal user. At least not against the register as such.
: Perhaps on the level of what prefixes got loaded into the document,
: but even then you would need to resolve a situation where (for good
: or bad reasons) a prefix is shared deliberately between packages.

When I wrote about rejection, I wanted to point out the
possibility. Of course you can also inform the package
writer. Informing the programmer is probably a better way.

: so I guess food for more thoughts here, but a formal and parseable
: interface on  kernel level may be a good idea, even if we do not
: directly use it to produce any external code or register
: updates/queries from within TeX

You could also introduce a kernel API to formally determine
the package writer, contact details, package dependencies,
and so on (all on a voluntary basis). This would really be
useful information.

Regards,


Marc