Since we covered some of the key components of content management, independent workflows and complex story relationships, we have to look at the other end of publishing: delivery. Once we've defined our data and presentation, what do we have handled by our delivery engine?Many systems in use for solving publishing problems suffer from low performance ceilings because the delivery system is going to a data store (a RDBMS, an object database or some other lookup process) to fetch and format. It's an accepted given that maintaining complex relationships between editorial objects mandates storage in such a system, but why make the HTTP request fulfillment performance hinge on retrieval? Doesn't it make more sense to calculate in advance that which can be so that the HTTP server can do what it does best, serve files?
Not all content components can be statically pre-calculated but if 90% of a presentation only changes episodically, not on a per HTTP request basis, we re-calculate 100% of the presentation on a per HTTP request basis?