Caching and headers

[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.