While I think your local caching solution is great, the problem comes up again when the site is big enough to scale large, and needs a true external cache-able solution that can still function with this great idea.

See http://esi-examples.akamai.com/ua.html

Essentially, if this is going to work, you'd need to generate a page with multiple renders (all of the optional ways to show it), and then that way Akamai would have all of the page templated layouts there at the same time, waiting to figure out which to display to the user. Of course, that's all for anonymous users, so it can be cached, same as Drupal's local issue.

Comments

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Active » Closed (won't fix)

I will not provide support for a language I do not know (let alone that seems to be relatively new). This module meets the requirements of Drupal: Apache, ProgresSQL/MySQL[i] and PHP. I welcome caching ideas that flow with the accepted coding standards and methodology that Drupal requires.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Closed (won't fix) » Active

I need to apologize. I was extremely coarse in my reply and feel I need to explain a little more:

I took a look at the link you provided and I am confused as to what exactly you mean. I do not understand what it is Akamai ESI is or what it accomplishes. That being said...

This module works in the following manner:

1) Determine which browser is requesting the page based on the $_SERVER['HTTP_USER_AGENT'] variable that is sent via PHP
2) Uses the module Browscap to parse that string into an array of information, of which I use "browser", "major" and "minor"
3) While Drupal typically looks for the default "page.tpl.php", this module enhances that by look for additional browser based templates (you can read this project's page detailed information)
4) Caching only plays a part for the anonymous users and if you even have it enabled in Drupal. If that is the case, this is why I created the cache include file that prepends the CID that drupal uses for page calls with the relevant browser information

You say "true external cache-able solution". I am a bit perplexed as to why you need external caching at all, just being honest. Maybe I just haven't worked on something that big to need it. Although... I would be glad to keep this dialog open to enlighten my understanding for this need and maybe create an appropriate solution.

sethcohn’s picture

sethcohn commented

Mark, first I love the module and the approach...

The problem is it's essentially 'uncachable' otherwise... you can't use any of the known scalable methods, of which there are plenty, because of step 1+2. Your Drupal server must always decide in each case, which version to show....

Akamai and other 'CDN' solutions take anonymous content, and store it in edge servers, so they can serve it up to thousands, essentially taking that load entirely away from your system. So Step 1 doesn't happen, let alone the later steps.

My proposal was (for _anonymous_ users, since that is the real issue), to build a page that would use Akamai's own version of Step1+2 (ie thru ESI), feeding it content with _all_ of Step3's variations (ie here Akamai, here's all my variations of this page), and let it choose display the correct version.

Yes, it's a bit beyond the scope of your module, but most folks with a need for massively different pages for various browsers is also like to need to scale up greatly as well... the overlap in needs is big. Your module won't work with external caching, of any sort, right now.

Not a flaw, by any means, just a feature request. And feel free to make this as 'by design' and close it.

markhalliwell’s picture

markhalliwell
Primary language English
commented

So I suppose my next question would be: is the Akamai module what you are looking for? I feel like I'm missing a huge portion of what you are trying to get across and I would like to help make this module happy with others :)

I have been trying to research how the Akamai process actually works and if I know the logistics behind it I could help a little better

sethcohn’s picture

sethcohn commented

No, not quite what I meant.

ESI = http://www.w3.org/TR/esi-lang

"Edge Side Includes (ESI) is an XML-based markup language that provides a means to assemble resources in HTTP clients. Unlike other in-markup languages, ESI is designed to leverage client tools like caches to improve end-user perceived performance, reduce processing overhead on the origin server, and enhanced availability. ESI allows for dynamic content assembly at the edge of the network, whether it is in a Content Delivery Network, end-user's browser, or in a "Reverse Proxy" right next to the origin server."

Akamai supports the spec very well.
Varnish supports a subset (not sure if it's enough in this case, though): http://varnish-cache.org/wiki/ESIfeatures

The idea, as I said above: when caching for anonymous users, the original (Drupal) server may not be involved at all. So what I proposed would essentially let you push the various results of the browser-type processing outward to the cache servers. Instead of having to locally figure out "this is Browser A, return Page formatted for A" OR "this is Browser B, return Page formatted for B", you'd create a single page (designed specifically to go into the cache) with BOTH A and B versions, plus some code (ie ESI) designed to let the cache server decide which version (A or B) to send to each client.

Clear?

markhalliwell’s picture

markhalliwell
Primary language English
commented

Ok, sorry for taking so long to respond. I have been focused on other areas as this module never really took flight. After rereading what you wrote just now, and a little more of how theming works, I am starting to get what you are saying. However, I suppose this module came into existence because my production sites have no use for external caching so I have real little knowledge of the subject.

So, to help paint this picture a little clearer. I think what you are saying is that you would like the ability to keep your different template versions in separate .tpl.php files, but have a setting like "Enable Akamai Support" that would override the suggestions with "page-akamai" or something of the like. Granted you would have to build the page template yourself as this is more of a theming issue at that point... you would just like this module to be aware that this is what is happening, yes?

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Active » Closed (won't fix)

Project is dead and will no longer be supported.