Caching and headers

[eluser]Randy Casburn[/eluser]

I’m not sure what you’re getting at...

Many, many folks here cannot explain themselves because they don't have the depth. You clearly have a handle on this. Good explanation.

I hope that explains a usage scenario for you.

Yes.

Regarding Seppo's quote: He's quite good. There are many ways to cache content other than CI. I don't actively use the CI cache mechanism either. I probably would have given the same answer.

And I will point out again that I’m not trying to do anything extra-funky here

Sure, I'll go on the record and agree with you in that statement for sure.

Nor am I creating any new errors...

Well, this is where we part company. I agree you are not creating ERRORS, but you are COMPOUNDING difficulties by making them more apparent. Plus, this patch will likely break other applications that have been patched to work around this problem using other methods. (That is what causes the consternation about the Suffix issue). So where do we go from here?

I think you've got a compelling and supportable argument if you meet a couple of conditions:

1) You must satisfy the backward compatibility issue for those that already have patched this issue in whatever method they have patched CI. That means if they call it Suffix or Australia or Zambia that you are obligated to ensure that your solution will provide a solution that will provide a working solution for them as well in a highly backward compatible way.
-- As an example, View chaining is supported by CI. So if you offered that chaining your mime type views other than text/html (js/css/xslt/json/etc) one after another, then all the headers in the set_header() calls would be pushed into the header[] array and they would ALL be cached together. This is one solution to the Suffix type of problem, but only if the community would accept it as such.

2) You must convince the community to implement, test, and report on the whether this is actually working. I don't think anyone has actually run this code (other than you most likely).

Sounds like a good effort,

Good Luck,

Randy

[eluser]Aquillyne[/eluser]
[quote author="Randy Casburn" date="1216717264"]Sounds like a good effort[/quote]

Thanks!

[quote author="Randy Casburn" date="1216717264"]You must satisfy the backward compatibility issue for those that already have patched this issue in whatever method they have patched CI.[/quote]

Well, throw me a way in which it might have been patched, and I'll say if this breaks. However, I can't imagine how this would break any prior code. Here's why:

1. If their patch works by extending the output class and therefore overriding the core functions, my section of code won't even run - theirs will.

2. If their patch is a hook that overrides the output mechanism then again my code won't run, theirs will.

3. If their patch is a hack to the core functions then they've already accepted that if they overwrite the file with an update they'll overwrite their own hack. They can reincorporate.

4. My code doesn't interfere in the slightest to any current, unpatched applications using caching.

I can't really see any other way of achieving what I'm achieving here, so I don't think there could be backwards compatibility issues.

[quote author="Randy Casburn" date="1216717264"]View chaining is supported by CI. So if you offered that chaining your mime type views other than text/html (js/css/xslt/json/etc) one after another, then all the headers in the set_header() calls would be pushed into the header[] array and they would ALL be cached together.[/quote]

I don't follow your example mainly because I only have a vague idea of what view-chaining is. But let me interpret.

If you're suggesting that one controller might be attached to seventeen different views, some of which might even have views inside them, and that various of those views will be sending headers, then yes, every single one of those headers would be re-output along with the page on the next load.

In other words, with my addition, what you get to the browser (headers and content) is what comes to the browser every time, regardless of whether you're caching.

[eluser]Aquillyne[/eluser]
[quote author="Randy Casburn" date="1216717264"]You must convince the community to implement, test, and report on the whether this is actually working. I don't think anyone has actually run this code (other than you most likely).[/quote]

I've been running it. It works a dream. What gets to the browser on the first load is what gets to the browser on every load.

How might I go about asking the community to test this? Care to lend a hand by giving it a test yourself?

[eluser]beemr[/eluser]
[quote author="Aquillyne" date="1216712971"]

Code:

$data["body"] = array("background" => "white");

$this->load->view("styles/css_file", $data)

The view simply converts that $data into a CSS document, e.g.:

Code:

body {
background: white
}

[/quote]

Essentially, you will be managing controllers/methods for each of your assets as well as controllers/methods for your site URLs. That's more complexity than I would want to see. At that point, I'd just build static assets and embed specific css and js to the page.

[eluser]Aquillyne[/eluser]
[quote author="beemr" date="1216718523"]Essentially, you will be managing controllers/methods for each of your assets as well as controllers/methods for your site URLs. That's more complexity than I would want to see. At that point, I'd just build static assets and embed specific css and js to the page.[/quote]

There are various benefits to managing a controller for CSS.*

But as stated, this thread isn't about a solution to a mimetype/CSS problem. It's about the following, general problem:

If you send any headers at all (mimetype, whatever) along with your page, then they will only reach the browser on the first load, and never again, if caching is on.

Not very intuitive or useful behaviour. Why would you want to send headers that only actually are sent the first time the page loads? My patch sorts out this general problem that affects a whole host of possible applications, not just those associate with dynamic CSS.

* One that I'm fond of for its neatness is that it's more efficient (just if the caching works). My view file refactors all the CSS information into the smallest, tidiest possible CSS file. Minus the time and memory taken up by running that logic (i.e. if we're just delivering a cache), you get slightly better performance without having to actually code your CSS file in the above stated way - you can code it as untidily and wackily as you like, the view will sort it out. Other rather good things about controlling your CSS is that you can use PHP logic in it. Want to change the colour-scheme of the entire website just by changing 1 variable? Ok!

[eluser]Randy Casburn[/eluser]
@beemr -- Many Theme switchers are written this way.

[eluser]Randy Casburn[/eluser]
[quote author="Aquillyne" date="1216718111"][quote author="Randy Casburn" date="1216717264"]You must convince the community to implement, test, and report on the whether this is actually working. I don't think anyone has actually run this code (other than you most likely).[/quote]

I've been running it. It works a dream. What gets to the browser on the first load is what gets to the browser on every load.

How might I go about asking the community to test this? Care to lend a hand by giving it a test yourself? [/quote]

No, like I said, none of my applications use the CI cache.

[eluser]Randy Casburn[/eluser]
[quote author="Aquillyne" date="1216717908"]
Well, throw me a way in which it might have been patched...[/quote]

Well, I would start by satisfying all the Suffix folks (is that just beemr?)

[eluser]beemr[/eluser]
@randy - That's the sweet spot for CI. Aquillyne can write a theme switcher. I can write suffix conventions. And because the whole framework can be extended, there is a safe path for variation.

@Aquillyne - none of your view CSS features are negated by the suffix. The suffix will just help prevent name collisions between your cache files.

[eluser]Aquillyne[/eluser]
[quote author="beemr" date="1216722362"]@Aquillyne - none of your view CSS features are negated by the suffix. The suffix will just help prevent name collisions between your cache files.[/quote]

[quote author="Randy Casburn" date="1216719627"]Well, I would start by satisfying all the Suffix folks (is that just beemr?)[/quote]

Heh. Last time. This is nothing to do with Suffixes. This patch does not address, interfere, interact, or have anything to do with suffixes. That's a totally different patch which could be used together with this one, as per Suffix cache (see the wiki).

@beemr - I presume you're saying the same thing? Actually, all the CSS features I've described work with or without cached headers or suffix extensions. It's just that with cached headers, they can work a hell of a lot more efficiently.

(And with suffixes, I can name my CSS controller = normal controller . ".css"; - but that's not an issue for me anyway, as I've named it totally differently).