This is the mail archive of the mailing list .

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[docbook-apps] Dynamic web serving of large Docbook

Hello all,

I'm scouting for a solution for a large Docbook/website project, and perhaps 
someone have had similar problems.

Here's the situation:

The sources stretches over several books and over 500 pages, and multiple 
authors are working and updating on a daily basis. It's maintained in a CVS 
repository, and the document's primary usage is on a website which 
occasionally should handle traffic corresponding to a slashdotting without 
requiring manual intervention(switch to serving true static files, for 
example). The output would be with the navigation structure(chunked), and PDF 
files for each chunk.

One solution is to do an ordinary transformation, run by a cron/makefile 
script. But this is inflexible, since other content needs dynamic generation, 
and it also -- actually -- becomes a performance issue since it involves many 
files(largely because it's chunked PDF too); especially since the script would 
have to be run with short intervals in order to avoid long waits between 

The perfect solution, AFAICT, would be a dynamic, cached, generation. When a 
certain section is requested, only that part is transformed, and cached for 
future deliveries. It sounds nice, and sounds like it would be fast.

I looked at Cocoon( for helping me with this, and it does 
many things well; it caches XSLT sheets, the source files, and even 
CIncludes(same as XIncludes basically).

However, AFAICT, Docbook makes it not easy:

* If one section is to be transformed, the sheets must parse /all/ sources, in 
order to resolve references and so forth. There's no way to workaround this, 

* Cocoon specific: It cannot cache "a part" of a transformation, which means 
the point above isn't workarounded. Right? This would otherwise mean the 
transformation of all non-changed sources would be cached.

This is further encumbered by that chunked output doesn't send to standard 
out, but write to files. Probably my knowledge about Docbook & Cocoon is too 
low, but perhaps it can be workarounded, or that it is no problem for Cocoon.

I tried playing with the rootid parameter, but it didn't matter as Bob's 
Docbook XSL: The Complete Guide said. A document that takes 11 seconds with 
xsltproc(fast..) on a idle modern computer, took 7 seconds when only a small 
section was outputted. Not enough.

I've asked on the cocoon-users list, but there was no enlightening replies.

Feel free to clear my confusion. What it basically boils down to, is:

Is there any way to generate parts from a Docbook Set in a quick way, suitable 
for dynamic web serving?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]