Malcolm Tredinnick wrote: > Since we already have middleware for attaching ETags (CommonMiddleware) > and supporting conditional GETs (ConditionalGetMiddleware), it would be > nice to work out why they aren't just doing the right thing here. I found ConditionalGetMiddleware before I wrote my extra view.
My problem with the CGM is that *first* it completely and totally does the work of generating the RSS page, and then, only just barely before we're about to send it out, decides to throw it away and return a 304. It helps with bandwidth, it doesn't help with the CPU time to generate the RSS feed in the first place. You say later the server CPU hit for generating the RSS feed is minimal, but RSS feeds are special; they can easily make up over 50% of a server's requests. RSS generation can actually be the "nested inner loop" that you need to optimize. So I advocate a bit more special-case support to make sure that cache control is as effective as possible and as easy as possible, especially as (IMHO) I'm not really advocating anything *that* special; the result is a view that's only about twice as long as the existing rather short one. It still fits on one screen for me. > So I'm going to skip over your design, since it looks right in general, > but is a repetition of how the ETag generation and conditional GET > support already works (for some broken definition of "works", > apparently :-) ). Duplicated versions of identical logic is not going to > be our friend here. > I don't think what I'm looking for can live in the Middleware layer, because I'm trying to bypass generation entirely. I also have not found any code that helps people generate the E-Tag and Last-Modified information; CGM is only a consumer, my API is for a producer. Are you referring to something else? Conceivably, a new Middleware that was based on giving Views the ability to declare what objects they are going to render, and tell the Middleware about E-Tags and If-Modified-Since before allowing it further down the stack could have application beyond just RSS feeds, but I have been hesitant to suggest this because it leads down a road that has cascading consequences. (Bare minimum, a Middleware would need to communicate and/or know about the view, which is already a significant API modification, and now is a bad time to advocate that. I also think that if you follow this logic, you naturally end up with Views becoming instances of a class, instead of functions, because the natural way for Middleware to interact with views is via methods; decorator hacking or (heaven forbid) "calling the view with special arguments" reduces to method calls anyhow; you're just trying to hide that fact and making it more complicated in the process if you do those things. My opinion that this is actually inevitable in the long run, but I have no intention of championing just before a 1.0, unless a core dev jumps up and shouts "Yes yes we so need that!". In a perfect world, this probably *is* the solution, but it is not currently practical or desirable.) So the core E-Tag/Last-Modified code logically needs to live in the Feed view; we can't build it off Middleware. I don't think this poses a practical problem, because the goal is that people aren't writing the Feed view anyhow. If we really want to be hard-line about "no code duplication", which is probably a good thing, the ideal is probably to pull the logic in CGM out into a separate function which both CGM and the Feed view could call. (Hmm, actually, looking at the CGM the "process_response" could be renamed to something like "return_304(cls, request, response)" and turned into a class method, and a new "process_response" could then dispatch out to the class method instead. My current view could then use the CGM logic as-is, as could anything else, and the CGM functions as it currently does. Probably shouldn't turn "process_response" into a class method directly; that's asking for trouble down the road, plus the class method really needs a descriptive name. If we do this, then the resulting new feed view would probably have only about five or six new lines in it. I like this.) > I think you've identified a genuine problem (or at least a problem in > the way I've configure my server), so it's worth investigating what's > going wrong. It may be that we need the ability to control some headers > in the feed generation to indicate "really not changed" even though the > exact sequence of bytes may not be identical. But let's work out that > that is the case first. > You can handle this in your E-Tag code; this is part of the reason the added E-Tags in HTTP1.1 in the first place, Last-Modified is more brittle in this case. I'm happy to push this responsibility onto the handful of users that realize they want or need such support. The documentation for this change would require a description of what the E-Tag should contain (with reference to the HTTP standard), the fact that you can diddle with the E-Tag this way may warrant a parenthetical note. > Previously, testing this type of thing was quite hard because of the > lack of support in our test framework for HTTP interactions. But Russell > has fixed that over the last few months. I figured that was it. >> * Any interest in using Last-Modified to hack on the RSS feed to only >> return items that have a date after the Last-Modified? I've always >> wondered why more dynamic systems don't work this way... maybe somebody >> knows a good reason. (This would get your RSS feed down to the bandwidth >> of sending each item exactly *once*, and a series of Not Modified >> returns... pretty close to optimal bandwidth usage. If it works.) >> > > One big reason for sending out coherent copies is upstream cache > support: if you keep sending out changed versions like this, you are > only considering things from the point of view of the generating server. Ah, yes, I get it. That answers that. Saves me that much more work. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
