User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0)
            Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
References: <514443C4.1080503@morningstar2.co.uk>           
            <20130316121332.GA5586@csmvddesktop>           
            <51458BC2.6060701@latex-project.org>
            <20130317102834.GB6929@csmvddesktop>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <5145AA6A.6030004@morningstar2.co.uk>
Date:         Sun, 17 Mar 2013 11:35:06 +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: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Prefix database
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <20130317102834.GB6929@csmvddesktop>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 17/03/2013 10:28, dongen wrote:
> : 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?''

That we have an answer to: me :-) (Or at least I'm prepared to do it as
I see long-term utility in being able to look up what is in use and who
is using it.)

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

Rejection is perhaps a strong term: I'd hope we can look to talk with
programmers to make the best use of the namespace.

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

Much as I'd imagined: see my other mail.

What I do notice is that there does seem to be some feeling this is a
good idea, both within the TeX community and as I've pointed out based
on what other groups do (particularly Perl).
-- 
Joseph Wright