[tex-k] accessing MySQL w/kpathsea

[Johannes Wilm]

On Thu, Jun 12, 2008 at 7:59 AM, Karl Berry <karl at freefriends.org> wrote:

>    What about bibtex? Wouldn't the same problem persist there?
>
> I don't know what "problem" you mean, but yes, our implementation of
> bibtex uses kpathsea (as you know), and so all the same stuff applies.
>
>    bibtex-like functionality should be pretty much be workable directly
>    through luatex now
>
> I don't understand.  BibTeX has its own job to do.  Sure, I guess you
> could reprogram it in Lua, but I don't see the point.
>
> BTW, there is an experimental package which does *all* formatting of bib
> entries using LaTeX, and just uses bibtex for sorting.
> http://www.ctan.org/tex-archive/help/Catalogue/entries/biblatex.html
>

Yes, I did the Danish and Norwegian translations for that package. It was
that or amsref which I figured combined with Lua's new indexing/sorting
functions should be able to work completely without bibtex.

 The point would be to avoid having to run several programs at all. And, as
it seems you try to point out, it doesn't really work to work on luatools
instead of kpathsea, if luatools only works for one of several programs that
need to be used.

However, if there are no plans to fix bibtex, then clearly it will never
work to write a luascript rather than a hack to kpathsea.

>
>    But these files are searched according to different path-values, right?
>
> Sure.
>

Ok, then that wouldn't be an issue, I would think.


>
>    Are filesystem lookups that much faster than database-lookups?
>
> It's never been compared, that I know of.  I don't think you can make
> any general statements about it.  It probably depends on many factors,
> like the size of the caches on the hard disk, the speed of the cpu for
> the database, how the database is indexed, etc., etc.
>

No, that's why I wondered why it should be such a problem to make 200 db
lookups, if it's currently doing the same amount of filesytem lookups.

>
>    Am I completely off here?
>
> Is this all about speed?  I wouldn't expect any huge speed gains from
> using an sql database.


Well, that is one of the reasosn why websites generally work on databases
rather than files on the harddisk. But more so it's about keeping different
user accounts seperated from oneanother, and to keep diskwriting operations
donw to a bare minimum.

>
>
>    These are textbased databases, as far as what I get. Are
>    lookup times in them faster than in a mysql-base?
>
> Again, I don't know, but I highly doubt it's significant.  All kpse does
> is read ls-R (a relatively small text file) into a hash table.  It's
> hard to imagine mysql being much faster than that.  If there were
> millions of entries, it would be a different story, but thankfully
> there's not.
>
>    What do you mean? just redefine \input{XX} and \include{XX} ?
>
> No, nothing at the TeX level, that would be completely unworkable.  I
> meant a shell script that does the sql commands to extract the input
> file.  I thought you were aiming to create a specific application that
> needed reports formatted with TeX.


Yes, it's a editor which stores the documents in a database. Check out
http://www.latexlab.org . When someone clicks the button to make a pdf-file,
it somehow needs to do that.

Extracting one file wouldn't be much of a problem, but what about all the
potentially included files? One would either need to simply check out all
files a user has before compiling, because all of them might be included, or
intercept latex at the level of accessing the files -- the approach I've
presented here with hacking kpathsea.


>
>
> But now it seems you want to replace TeX file lookups, in general.
> About all I can do is wish you luck.
>

It is fairly straighforward just to pipe an individual latex-document. For
that no disk writing operations would ever be needed, and no fixes to
anything would need to be applied. The only time this could ever becoe an
issue is when files are included. As I understand it from your comments, the
onyl way to solve that is to hack kpathsea, at least unless there are plans
to rewrite bibtex.


Thank you very much for your comments though! And please feel free to
comment further if there is more information that is relevant to this task.


>    until luatex becomes usable --
>
> LuaTeX is usable.  Not stable/frozen, but usable.
>
>

> karl
>



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