Re: And again memory usage...

> That one could get along with a single executable and pool and format
> files for (PDF)?e?TeX, I already clamored about.  And people told me
> that it would be peanuts.  Never mind the peanuts, I think it
> worthwhile if people don't ask confused why some programs work and
> some not (some might need eTeX).

I  second you. And  pdfetex is way enough.  Especially on platforms like
windows where users don't   want to  seen   any mess with  thousands  of
files. They want to see only an icon on their desktop. Given that TeX
can dump its data, a format file, a binary program and a pool file
should be just enough to typeset texts. Add some fonts and map files to
generate PDF. Ok, that breaks the current model, but that would be much
closer to what a novice user expects_*_. Context is quite close to
achieve this.

> What we need is not a filename database.  What we need is a file
> database.  We need to have all files in the texmf tree stored
> compressed in a database. 

Sure. The problem is to rely on some external tool to serve the files if
you want to be cross platform compatible. I don't think the current
kpathsea API has ever been developed with this in mind. It is not
reentrant. Karel Skoupy kpathsea server is the closest thing I know of
to meet your requirements (see TUG2002 proceedings ?).

-- 
Fabrice

_*_ Same with (x)emacs by the way :
why not dump all those .el files rather than dump half only half of them
and let the system load the other half at runtime?