* Frank Mittelbach <[log in to unmask]> [2013-03-17 10:24:18 +0100]:
: 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
: 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