Caching and headers

[eluser]Randy Casburn[/eluser]
@beemr - I don't care about the suffix thing that is all you. I'm attempting to arbitrate. If you don't speak up and clearly take a position against this patch, I'm going to get on the band wagon and start to advocate the hell out of it. This has big and positive implications for CI and the community. The only nay sayer is you as far as I can tell and I've been supporting you.

Are you against this change or not? up or down?

Randy

[eluser]beemr[/eluser]
I'd rather that CI took a more complete view of serving type headers, rather than just solving Aquillyne's need for php-based css.

When serving types such as RSS or PDF, it is organizationally advantageous for both the user and the developer to have the same controller/method pushed to a variety of formats rather than a loose collection of URLs to do the same. Example.com/company/groups/Board_of_Administration should have its RSS at Example.com/company/groups/Board_of_Administration.xml or ".atom". Without suffixes to differentiate, we'd be forced to manage separate controllers for each in order to avoid cache conflicts. Yes, you could add an extra segment, but if you need to add parameters, you will find yourself testing for a "format segment" before you can address segment parameters. Suffixes avoid that spaghetti.

Suffixes combined with cached headers, as they are in Suffix cache, give us the basis for overloading our controllers, thereby establishing a convention that will reduce configuration. For example, I am using the suffix to identify Ajax requests. Since the suffixed Ajax request is using the same controller as its form, I am returning Ajaxified validation messages from the very same rules that a form submit would use. That means I only have to maintain one form, even as I get two distinct use-cases from it.

I think CI would do well to consider suffix-based content negotiation for its core. Rails has it. It encourages sensible structures. Simply adding cached-headers without a path for suffixes would encuorage abitrary structures and diminish convention.

FYI, both Aquillyne's code and my library extensions are derived from Josh Surber's patch. His post might explain this better than I have.

[eluser]Aquillyne[/eluser]
[quote author="beemr" date="1216768872"]I'd rather that CI took a more complete view of serving type headers, rather than just solving Aquillyne's need for php-based css.[/quote]

Ah but for the millionth time, nothing about this patch is just solving my CSS-based needs. This patch fixes a general problem that, among many other things, does happen to solve my CSS-based needs (and some others too). This patch solves the general problem that CI doesn't cache headers.

[quote author="beemr" date="1216768872"]When serving types such as RSS or PDF, it is organizationally advantageous for both the user and the developer to have the same controller/method pushed to a variety of formats rather than a loose collection of URLs to do the same. Example.com/company/groups/Board_of_Administration should have its RSS at Example.com/company/groups/Board_of_Administration.xml or ".atom". Without suffixes to differentiate, we'd be forced to manage separate controllers for each in order to avoid cache conflicts.[/quote]

I agree with you. But this patch is nothing to do with suffixes. That's a separate issue which we might seek to fix another time. It's one you seem desperate to fix, as you go on:

[quote author="beemr" date="1216768872"]Suffixes combined with cached headers, as they are in Suffix cache, give us the basis for overloading our controllers, thereby establishing a convention that will reduce configuration ... I think CI would do well to consider suffix-based content negotiation for its core. Rails has it.[/quote]

You're basically suggesting we patch even more than what I'm suggesting. You want to patch the CI core with Suffix cache, which is basically MY patch plus one that makes CI recognise suffixes. You're trying to solve two problems at once. Hence I guess you're not against solving just one?

Wait, maybe you are:

[quote author="beemr" date="1216768872"][Fixing suffixes and header caching, rather than just header caching] encourages sensible structures. Simply adding cached-headers without a path for suffixes would encuorage abitrary structures and diminish convention.[/quote]

But let me remind you of one of the tenets of CI:

From the CodeIgniter Front Page:
CodeIgniter is for you, if:
* You want a framework that does not require you to adhere to restrictive coding rules.

CI isn't about forcing people to code sensibly, or any way at all. It is, however, about functionality. The patch I'm suggesting adds functionality where it's sorely missing. Indeed, I might even go so far as to call my patch fixing a bug.

The discussion of suffix recognition is for another time on another thread.

[eluser]beemr[/eluser]
Recognizing suffixes will not restrict you from coding a separate controller for each asset. You will still be able to ignore suffixes altogether. Just as CI allows you to serve ".html" or not. Your choice.

[eluser]Aquillyne[/eluser]
[quote author="beemr" date="1216771786"]Recognizing suffixes will not restrict you from coding a separate controller for each asset. You will still be able to ignore suffixes altogether. Just as CI allows you to serve ".html" or not. Your choice.[/quote]

Sigh. I know the benefits of suffixes. But really, I'm not talking about them, and I never was.

I you want to advocate a patch for suffixes, please do. I'd probably back you.

But you're coming across as antagonistic to this patch proposal. If you are, I'd like to hear what's wrong with it. Otherwise maybe you'd like to either back it, or back it as part of your own proposal that also includes suffixes.

[eluser]Randy Casburn[/eluser]
May I arbitrate?

[eluser]beemr[/eluser]
It boils down to this:

You think that I'm trying to solve two problems at once.

I think you are solving half of a problem and potentially creating new ones.

You obviously have a purpose in mind for cached headers other than content-type. I don't. Content-type negotiation, whether by suffix and cached headers or otherwise, can be a big area of improvement for CI. For that matter, so might Activerecord Class Mod. However, I'm not going to just propose them as core changes.

Why not just extend the libraries you want to see changed, publish to the Wiki, and see if enough of the community is interested to elevate the extensions to EllisLabs? If you want me to, I'll turn your wiki into a MY_Output extension. That way, the community can try it out risk-free, and EllisLabs will be able to see the buy-in before they make your core changes.

[eluser]Aquillyne[/eluser]
[quote author="Randy Casburn" date="1216773432"]May I arbitrate?[/quote]

Whatcha mean Sure.

[eluser]Randy Casburn[/eluser]
Please consider both of these quotes...

it is organizationally advantageous for both the user and the developer to have the same controller/method pushed to a variety of formats rather than a loose collection of URLs to do the same

AND

If the suffix is recognised then I can get a separate cache for foo.css and foo.js. Fantastic. But still, neither of them, when the cache is delivered, will be accompanied by their respective “text/css” and “text/javascript” headers. That’s the issue I’m trying to address. Regardless of how the cache grabs the URI, subsequent returns of the cache don’t also return the appropriate headers.

These sound like "my way or the highway" types of language. I mean really. The first, while it may be true or not, sounds like "one view of the world". Someone else may have a different view. That makes it an "implementation". That makes that reasoning a little weak because not everyone will "implement" that way. Perhaps that's why there is debate about it.(?) The second quote is simply "I refuse to listen to the fact that I can have any impact on you "because I don't see it that way". And that is simply wrong headed IMHO.

Now to be fair...

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

AND

Well, this is where we part company. I agree you are not creating ERRORS, but you are COMPOUNDING difficulties by making them more apparent.

The first quote I said about the solution not being anything funky. The second quote I said about the solution too.

==========

Can I encourage us to restructure our thinking on the entire issue?

==========

Let's call this:

CI MIME type caching.

Possible Help Documentation
---------------------------
By default, when caching is turned on, CI will cache your output as type text/html.

Simultaneous caching of other MIME types is also supported. This would allow you to maintain a long term cache of one file while periodically updating other files without the need to update your entire cache. As an example, you may send dynamic CSS from a View file and have that CSS saved to a cache. The CSS cache file may rarely change. The CSS styles may apply to an HTML View file that is saved to a separate cache file that can change independently of the CSS cache. This could also apply to a separate JavaScript file built from a View file and saved independently to a separate cache file. Now if you edit your JavaScript View content the only the JavaScript cache will require a refresh while the other cache files will remain untouched.

To implement this you will be required to use the Ouput class' set_header() function to ensure that you set the correct mime type header for the file type that will be cached.

For example:

Code:

[ controller ]

$data["body"] = array("background" => "white");
$this->output->set_header("Content-Type: text/css");
$this->load->view("styles/css_file", $data)

[ view ]

body {
   background: white
}

===========================

Now, let's figure out a way to have CI provide this functionality. Forget everything you already know about how to do this. OK, that's probably unrealistic. But we can do this with out all that other "my way or the highway stuff" right?

@Derek(s) -- Don't you think this would be good for CI?

Randy

[eluser]Aquillyne[/eluser]
[quote author="beemr" date="1216773854"]Why not just extend the libraries you want to see changed, publish to the Wiki, and see if enough of the community is interested to elevate the extensions to EllisLabs? If you want me to, I'll turn your wiki into a MY_Output extension. That way, the community can try it out risk-free, and EllisLabs will be able to see the buy-in before they make your core changes.[/quote]

I seeeeee.

This was my original gripe. It's a horrible MY_Output extension. The code I've given is a mix of original code and basically 10 lines of new or changed code. You'd have to extend the output class and override 2 core functions, each of which is about 70 lines long - so 140 lines - just to effectively change 10 lines. It's ugly.

I'm proposing this as a patch outright because I can't see how you, me, EllisLabs or anyone wouldn't benefit from it immediately. As I demonstrated earlier, it cannot possibly break any existing code, it only adds functionality in a place where it's so clearly missing that the CI code contains a comment bewailing it's absence. I'm proposing a core change rather than a class extension because it's not adding anything: it's fixing a problem with one of CI's core functions, caching.