[tex-k] accessing MySQL w/kpathsea

[Johannes Wilm]

Thank you so much for your very helpful replies. I have added another few
questions below.

On Wed, Jun 11, 2008 at 2:57 AM, Karl Berry <karl at freefriends.org> wrote:

>    It seems that at least for the moment, Luatex is still working using
>    kpathsea:
>
> Others know better than me, but my understanding is that there is a mode
> in which you can turn off the original libkpathsea C functions, and
> instead use Hans' reimplementation in Lua.  (Thankfully, this is not the
> default, or luatex wouldn't be remotely compatible with the rest of the
> distribution.)
>
> I do believe that Hans has already implemented a mode where the files
> will be found *inside* a .zip archive (or whatever).  Perhaps that could
> be adapted to db lookups.  In any case, you might indeed find it more
> rewarding to program your work in Lua instead of C.
>

Ok, yes that sounds at first really promising. But the code is usuable as it
currently is? I'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.

What about bibtex? Wouldn'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't seen any project with that.
Are there no othe intermediate steps that

>
> Anyway, back to your original question, which is more or less
> independent of the above, seems to me.
>
>
>  ".:/usr/local/texmf:[[database=mysql,dbserver='localhost',dbusername='USERNAME',dbpassword='PASSWORD',query='SELECT
>
> Sounds vaguely possible, I guess.  But you realize there are potentially
> hundreds of files being read?  Fonts, .fmt files, etc.?  Are you going
> to put the entire TeX tree into your database?  Yikes.  Well, I wish you
> luck :).


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  hasn'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?

It would only be people's personal files that are inside the database. The
system files would still be on disk.

>
>    As I understand it, the way it works is that it gets handed a string
>    such as the following:
>
> In broad strokes, yes.  There are also ls-R files, !! specifications,
> and more that affect the searching.


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?

>
>
>    currently accessed file into a nice *.tar.gz
>
> Just BTW, that's possible now, with (e.g.), pdftex -recorder.
>

very interesting!

>
>    it would need to be closed
>
> Won't it close automatically when the process exits?
> Or else I suppose you could register some atexit kind of thing.
>
>    Do similar projects exist already?
>
> Not that I've ever heard of.
>
>    maybe you can tell me whether I'm looking in vain and should rather
>    start somewhere else…
>
> If all you want to do is manipulate your input files in a db, I'd just
> write a wrapper around TeX that does the extraction instead of changing
> kpathsea at all.  I can't say what specific issues you will run into,
> but it seems inevitable that the whole thing will become quite a large
> project.
>

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.


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.

Thanks again for your advice.


>
> Best,
> Karl
>



-- 
Johannes Wilm
http://www.johanneswilm.org
tel: +5059173717
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tug.org/pipermail/tex-k/attachments/20080611/9af8f253/attachment.html