ESI API

This module is a low level ESI handling API for module developers and a besic block integration for site admins.

It handles ESI tag build and different levels of caching policy. It is able to cache blocks itself using complex cache identifiers computed using series of variables.

It provides a downgrade mode that is able to load all ESI elements using a simple and efficient piece of JavaScript if the site is not behind an ESI gate.

You can use this module safely without any ESI gate if you need to provide comprenhensible and fine tunable block AJAX loading/caching mecanism.

Technical notes

• It relies on a variable system, provided by implementors then used to compute cache identifiers.
• Strong caching policy, overridable easily by implementors (can be disabled on a per element basis).
• It stores and restores core execution context from the original page the most it can, in order for modules to be able to generate data without worrying about the ASYNC context.
• Uses the menu router 'theme callback' and 'delivery callback' for integrating to core, which makes it efficient and comprehensible (no exit() in AJAX/ESI callbacks)

Integration

Core block integration is provided.

Comparison with the legacy ESI module

Actual available D6 version of ESI module does not provide any kind of API, this why I wrote ESI API. Because D6 version is rather old and does pretty much nothing except exposing blocks via ESI tags, I can only try to guess what are the differences between what they are doing, so here it is, let's start with assumed similarities:

• ESI API provides a full API, which ESI D7 version will probably do.
• I can safely assume that the ESI API cache mecanism is different than ESI module (ways to do it are infinite, so its not likely they did the same thing). But I can also safely assume they also have an efficient have one.

And the assumed differences:

• ESI API modules provides a graceful AJAX downgrade mode, when no ESI gate is present (needs the admin to check a button to downgrade). The ESI module probably won't since they asked me for this particular bit of code.
• I cannot guess this one, but ESI API makes an heavy usage of menu API internals to ensure maximum responsivity during ESI/AJAX callbacks.
• ESI module evolution seems to be focused on PressFlow Drupal fork, which is probably a good idea, but also far away from core.

ESI module maintainers actually did asked me to join forces, which I'd be pleased to do, if I could see their code. They must be in an active developement phase else it would have be seen somewhere.

Roadmap

• Integration with the Varnish module if it'll be ported to D7 one day.
• More generic ESI tag handling, with complex tag creation.
• Specific Varnish pieces of integration.
• In a nice solution is found, override aggressive caching mecanism in order to allow it full page caching for logged in users, and provide block handling fully using ESI.
• If a technical solution is found, provide a lighter bootstrap for ESI cached elements.

Downloads