Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id r2H9QLpb020006 for ; Sun, 17 Mar 2013 10:26:22 +0100 Received: from relay2.uni-heidelberg.de ([129.206.210.211]) by mx-ha.gmx.net (mxgmx010) with ESMTP (Nemesis) id 0LtmKr-1Ug9101SQn-0118JA for ; Sun, 17 Mar 2013 10:26:16 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r2H9ObqD026662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Mar 2013 10:24:37 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r2GN12aI001500; Sun, 17 Mar 2013 10:24:37 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 8283715 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 17 Mar 2013 10:24:37 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r2H9OalJ022928 for ; Sun, 17 Mar 2013 10:24:36 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id r2H9ON5o026607 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Sun, 17 Mar 2013 10:24:26 +0100 Received: from mittelbach-online.de (pD9FE2262.dip.t-dialin.net [217.254.34.98]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MVq96-1UF4MJ0WSm-00X70k; Sun, 17 Mar 2013 10:24:23 +0100 Received: from [192.168.123.100] (falco [192.168.123.100]) (Authenticated sender: frank) by mittelbach-online.de (Postfix) with ESMTPSA id C0112C0025; Sun, 17 Mar 2013 10:18:32 +0100 (CET) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 References: <514443C4.1080503@morningstar2.co.uk> <20130316121332.GA5586@csmvddesktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:xKQfp/ha+dZl4hHRgWDZBu4n5Wtnmtt2c+JqUVlVLOE ju1njW2mg9gBGp2bnViQFKevbc+BcuFV9w2bjdD0+h7NNCQbTx kfCtHrJ1tygxX3BgnCmgfKtR69qKpwcB4R3IgoHvOQy3DFWEGt /2aBzlwjHapA6/vZnXLw0a+fOn8tfvcGLld/8nPPaZ/goTgdn+ eJc0f6hw+BAF4X2YR+PM+FQ7AsuuSCKhmZyvRQdbad4ITDIAgn mvNNKRbLtgWyYrg9gh4GE+D2jyz5BE8NDCx+o48jLQsq6nYgfd gxLFeNQC51oAZ3Zl9IsSJm8JvZbAt91L1cWFeoCT5AAunVaI9P eO82sn1cJqkpuxvnAbX+gD9htOz94XtQEMGwCJ4Kh Message-ID: <51458BC2.6060701@latex-project.org> Date: Sun, 17 Mar 2013 10:24:18 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Prefix database To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <20130316121332.GA5586@csmvddesktop> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Envelope-To: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=V3; X-GMX-Antivirus: 0 (no virus found) X-UI-Filterresults: notjunk:1;V01:K0:73xMRSIpcgI=:HaV/Alb5rERJla28GU7f3T oUg8v11TMEuO8BIlrAoQ21gunAorHM06XWGN3CpGywfqwxnPHt8LZLc2PtLoYrp6SC31R6Y XAYsXA5tCEzok69Gil3JHNqp1x/04zqgsP/ASKCvEq7jScVFP60ZIh1o4VZt/Jv9xnOCde2 v/KoaxqXWObKJgxe3Vhqk31zKe8jJrWk5swYEKT7D5sPfrYnKCsMjdj3WugkhQYy6A/zvZ+ rusesUNuA+3qdku4JoLcGa9sCvPnpllLK+8O4kGqoAEfht6joVCgxzBcFLRXaMYZHJamlNR j2EataJux8Y80glVN++nZbB4xfK0qxSzGkfWcsgmuAoSI0PGSw90Bb2/gxp9jItX16rrtO0 e0+m6aeuXlJtTnY2HtqbHxy8iYYIyaPyzUgH3W9Z1gnYjz7d9hHKJLDe2CBAbzQrAoZnXL1 yMf5FGtWQBmW8fysHeMSs7aNDXM5sCyFJq43459tVegUsmCKBhJxVRtQjSUnKJWrATPcCcc Fw80p/CEV0vdyI1hqmrYUM1VMkttepqbOX/du/HXXo0Yy/XzKL2O++pj5PSuwOyqLuYASMR qM41nxJ7S7pcuzZ9pZGXKzNfT6brFYWQa/WqEEOvn0mktmKn5tBBdk+ajkqtCwNHOWJxmM4 12HJBYMF2fHJ0kNO9TOmxC4tqjB8it84WZeYvx3rCh3XACufzAtyb9OsyFrAIZt+9LobMvJ 0FF7kloqKxFwZcHcS9W4D5rRk9yGoAKi5bIaXRPPBJErjBMiLwLp0foGuNckT/5OHuwPrg8 rHWM9dnqScXreOmftlgej/svAvYKCOaSU3kvvjt7qp0R7rMujvW1rIAcqf+0mrA4eDlk+w9 ALarHIZRp/qiQwyn2bAJI1+9zEo7CVVAyKpcniqiSmHeyU4k3miTzr07L8FBG/Ne3WrLChW Pday77LhZy/L9SfXzrCDmDGzReJRBAQricJN7KS5yM9vIMBpSLu22Pm29zGcuCLUWhRrYEO z8p7Af5NfZHcsmg5pjUQM2UCKX47gzjIUkt5wraGuFMeNHVbkiS9eqsqUYPSGc3b3Qyqx2v SvmM77aHoMCSLPzS3yBpadnz0ChSEk0/STGlhtwES+bXUD/eeLKMyWq6GIsjCJeSF+97mAg VM3swTVGC8MXwmGx/KXV/4BzFXoTIpB64xi3/NPeIdhpQCIJZkExQgDN4MSN3FmQQLFy3DC YTvXaVCa5nsnie9tZ/wnxMTo8vQ/U/QM02xKxNqjnWSfLCkewH4QjiLz0HoAYDb9MaIPgk0 dERiQuEUNQMl4RGV6H689N84RpNSTfZPR7JQPndftruTMlnJu6GToZOTfx3zVvdWnc1WdsI jtsENlx8l0H33cK1d5SSOc8kBSTg+DK0H8V+HsjjQm33E23RVaTXPMit1tDbz68hcK8NoVu H1NnwMl1I= X-UI-Loop:V01:QocIagv3awY=:YsNnj6etXYFLPWYMP/9CEn+0EfRYSzhiapJci+Zr7BI= Status: R X-Status: X-Keywords: X-UID: 7188 Hi Marc > : I'd also like to strongly encourage developers to register their > : prefixes by submitting them either directly to the team, to me or to > : sending them to the list. I'll try to pick up new uses as they pop up on > : the CTAN list, but may not catch everything. > > There may be a better way. there may indeed. Guess what we are doing right now is feeling our way through it to find it. > > Why don't the latex3 team provide a kernel method that people can use to > register their prefixes? The idea is that this method takes the prefixes > as input and writes them to some auxiliary file. When a package is uploaded > to CTAN, all the CTAN team have to do is use the package once and add the > output of the auxiliary file to the prefix database. providing a kernel method might be a good idea to formalize and channel things but I'm not 100% sure that the rest of the suggested work flow is really improving the situation. 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. 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. > 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. 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 cheers frank