Thank you so much for your very helpful replies. I have added another few questions below.<br><br><div class="gmail_quote">On Wed, Jun 11, 2008 at 2:57 AM, Karl Berry &lt;<a href="mailto:karl@freefriends.org">karl@freefriends.org</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"> &nbsp; &nbsp;It seems that at least for the moment, Luatex is still working using<br>

 &nbsp; &nbsp;kpathsea:<br>
<br>
</div>Others know better than me, but my understanding is that there is a mode<br>
in which you can turn off the original libkpathsea C functions, and<br>
instead use Hans&#39; reimplementation in Lua. &nbsp;(Thankfully, this is not the<br>
default, or luatex wouldn&#39;t be remotely compatible with the rest of the<br>
distribution.)<br>
<br>
I do believe that Hans has already implemented a mode where the files<br>
will be found *inside* a .zip archive (or whatever). &nbsp;Perhaps that could<br>
be adapted to db lookups. &nbsp;In any case, you might indeed find it more<br>
rewarding to program your work in Lua instead of C.<br>
</blockquote><div><br> Ok, yes that sounds at first really promising. But the code is usuable as it currently is? I&#39;m trying to get it working with a live-tex installation adn trying to get some kind of latex.fmt and pdflatex.fmt made using the current SVN-version, but so far without luck.<br>
<br>What about bibtex? Wouldn&#39;t the same problem persist there? I presume that bibtex-like functionality should be pretty much be workable directly through luatex now, but I haven&#39;t seen any project with that.<br>
Are there no othe intermediate steps that <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Anyway, back to your original question, which is more or less<br>
independent of the above, seems to me.<br>
<div class="Ih2E3d"><br>
 &nbsp; &nbsp;&quot;.:/usr/local/texmf:[[database=mysql,dbserver=&#39;localhost&#39;,dbusername=&#39;USERNAME&#39;,dbpassword=&#39;PASSWORD&#39;,query=&#39;SELECT<br>
<br>
</div>Sounds vaguely possible, I guess. &nbsp;But you realize there are potentially<br>
hundreds of files being read? &nbsp;Fonts, .fmt files, etc.? &nbsp;Are you going<br>
to put the entire TeX tree into your database? &nbsp;Yikes. &nbsp;Well, I wish you<br>
luck :).</blockquote><div><br>But these files are searched according to different path-values, right? It would only be when one of the path-values is [[database=mysql..]], and only if it&nbsp; hasn&#39;t encountered anything in the previous paths that would look up the database. Are filesystem lookups that much faster than database-lookups? Am I completely off here?<br>
<br>It would only be people&#39;s personal files that are inside the database. The system files would still be on disk.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
 &nbsp; &nbsp;As I understand it, the way it works is that it gets handed a string<br>
 &nbsp; &nbsp;such as the following:<br>
<br>
</div>In broad strokes, yes. &nbsp;There are also ls-R files, !! specifications,<br>
and more that affect the searching.</blockquote><div><br>Yes, I noiced that. These are textbased databases, as far as what I get. Are lookup times in them faster than in a mysql-base? <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="Ih2E3d"><br>
 &nbsp; &nbsp;currently accessed file into a nice *.tar.gz<br>
<br>
</div>Just BTW, that&#39;s possible now, with (e.g.), pdftex -recorder.<br>
<div class="Ih2E3d"></div></blockquote><div><br>very interesting!<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
 &nbsp; &nbsp;it would need to be closed<br>
<br>
</div>Won&#39;t it close automatically when the process exits?<br>
Or else I suppose you could register some atexit kind of thing.<br>
<div class="Ih2E3d"><br>
 &nbsp; &nbsp;Do similar projects exist already?<br>
<br>
</div>Not that I&#39;ve ever heard of.<br>
<div class="Ih2E3d"><br>
 &nbsp; &nbsp;maybe you can tell me whether I&#39;m looking in vain and should rather<br>
 &nbsp; &nbsp;start somewhere else…<br>
<br>
</div>If all you want to do is manipulate your input files in a db, I&#39;d just<br>
write a wrapper around TeX that does the extraction instead of changing<br>
kpathsea at all. &nbsp;I can&#39;t say what specific issues you will run into,<br>
but it seems inevitable that the whole thing will become quite a large<br>
project.<br>
</blockquote><div><br>What do you mean? just redefine \input{XX} and \include{XX} ? Are these really all there are? What about Bbtex? Are all calls to include Bibtex-output esentially just calls of the \input{XX} kind? I just wanted to make sure that not some strange package has another way of inclusing files that are not covered by this and could screw up the whole system.<br>
<br><br>Seeing just that it should be filesystemlookup really is no more than very few lines, and at least in bibtex (which I checked), it seems to me that for now -- until luatex becomes usable -- a hack in this direction might still be the path of least resistance. but then, you guys are the experts.<br>
<br>Thanks again for your advice.<br>&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Best,<br>
<font color="#888888">Karl<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Johannes Wilm<br><a href="http://www.johanneswilm.org">http://www.johanneswilm.org</a><br>tel: +5059173717<br>