Instead of having to write customizations for each feature, have this module function like usual, but the AJAX part returns some sort of diff. That way almost any part of the DOM can be changed via jQuery. Not sure how feasible this would be, but just thinking of ways to take this far out, see what the limits are. It would allow for a very easy drop in cache system that works. Only problem is in order to create the diff you need to render the html all the way, so I'm not sure how to use this to speed up the page, other then the appearance of it being faster. Thinking of ways to remove the "final HTML of each cached page must be the same" and other hurdles.

Comments

Jonah Ellison’s picture

Jonah Ellison commented

Interesting idea, though you are right about it not reducing server resources and just giving the appearance of being faster, since the Ajax phase would have to render the HTML as a normal Drupal page request and send the result, then have the client parse & modify the DOM, which may cause some additional lag since the speed of JavaScript processing isn't the best. I'd be interested if you come up with anymore thoughts of this implementation or anything similar.

Requiring the final HTML be the same is definitely the greatest limitation of this module, but it also offers the greatest speed advantage. Once cached, it is extremely quick to retrieve and send to the browser. Also, once the browser has the page in its own cache, it stays there and the HTML doesn't have to redownload if the page hasn't been modified (Authcache uses the HTTP 304 Not Modified header), making the site appear even faster. So that's the tradeoff: speed in exchange for more development time for each dynamic piece of content.

mikeytown2’s picture

mikeytown2 commented

Another idea would probably involve some major mods to drupal. Have each element of the theme report if it's dynamic... (user input/behavior can change it). So Most elements would be static, and only the dynamic parts would then have to be processed. It would probably require a this-is-not-dynamic flag to be set in each module and theme, or...? It would be something to consider for 8.x, in order to support more exotic caching.

Going along these lines, have a cache for each input and output for a function. If the input's are the same (compare hash of it), serve the output straight from the cache; if different, calculate the output and store it for future use. This if implemented perfectly would allow for no expirations on caches. Taking D7's code registry to a whole new level. Each function knows what variables can change it's output, so if one of those variables changes then that function needs to be reprocessed.

moshe weitzman’s picture

moshe weitzman commented

For a function cache, perhaps borrow ideas from http://drupal.org/project/pressflow_preempt

fanzila’s picture

fanzila commented

subscribe :)

simg’s picture

simg commented

@mikeytown2

>It would probably require a this-is-not-dynamic flag to be set

isn't this functionality already pretty much provided by the block->cache value ?

simg’s picture

simg commented
Status: Active » Closed (works as designed)