Re: Re: [PEPr] Proposal for HTTP::HTTP_Cache

Hi, Michael Wallner schrieb:

        - The strong entity (i.e. ETag) can be used for unpersonalized
          as well as personalized content, because the ETag is validated
          against the actual body.  This means that caching by ETag can
          (mostly) only save bandwith, because one needs to know the
          entity from which the ETag is adhered, and the entity is
          usually generated at run-time.
I use it in conjunction with a server-side cache that is able to cache personalized content, by creating a cache key from a list of parameters returned by the components of the current page. This way I save cpu and bandwith (if possible)

        - One could use HTTP_Download do accomplish caching by ETag
          (while those routines may not be stable!), which has evolved
          to kind of a HTTP_Response package, with some features that
          would have been better split off.  One thing I never came
          around to implement is HTTP_Download_BLOB (volunteers?) that
          handles database blobs with a (sort of) stream interface.
I just took a closer look, this is similar to what can be done with HTTP_Cache, seems that currently all available classes that help you with HTTP caching seem to be split into several packages.

After all, I'm not anxious of a feature-rich, well-thought and separate HTTP_Cache package. It just shouldn't be yet-another-quick-shot.

    Maybe the implementor(s) should also have a look at Hordes Browser

package and its header routines for any browser quirks that might affect HTTP caching and have already been revealed. The most important question is: Are you willing to work with me on such a package? I think it would be great as you already maintain a lot of those HTTP_* packages.

Stephan