[PATCH] for adding options to expose()

[Florent Aide]

Hello,

I was trying to control the caching and found out I could not directly
influence on this in TG so I took my svn client and said : hey Flo
you're gonna have to send them a patch on this.

So here it is for your kind review and comments :)

http://trac.turbogears.org/ticket/1283

Please tell me if it has any chance to be accepted, what could be
changed, what you think of my bad coding practices...

This obviously lacks some kind of control like: if protocol number is
1.0 then raise an exception, but this is pretty easy to add if you
guys say that this patch can go in. If this is the case let me know
I'll be more than happy to cleanup a bit.

For the record it works on my machine on TG 1.1a0-rev#2549 running on
top of Portable Python 1.0 (2.5 based) on windows. Who said I liked
challenges ?

and now I am going to bed,

Regards,

Florent Aide

[gas...@gmail.com]

Looks not bad, would this improve the performance?

How about pass only one cache_control params and assign "no-store/no-
cache/max_age" for it?

[Florent Aide]

On 2/6/07, gas...@gmail.com <gas...@gmail.com> wrote:
>
> Looks not bad, would this improve the performance?

Using a mod_proxy or a reversed squid in front of this could help a
lot. But even just controlling the browser cache with this will
improve performances a bit.
One more aspect of this is that you theorically can force IE or any
proxy to NOT cache your content and thus make sure your method is hit
each time the user tries to view it.

I have another idea concerning an in memory cache for rendered views
that could be controlled with an expose() param specifying the
cache_ttl but I need to think about this and to make sure this is
doable/useful ...

> How about pass only one cache_control params and assign "no-store/no-
> cache/max_age" for it?

Not sure. This would require string matching which is cpu intensive
compared to boolean matching but why not.
The problem is I am not an rfc2616 expert but there seem to be much
more options and I don't have a clear idea of how to give access to
all this easily.

The easiest route seems to just give a cache_control parameter and
then let the user specify this header by himself (not really friendly
but powerful) and the second route is to provided different arguments
that help people set an header without having to fully read and
understand the rfc2616...

I am open to any option.

Regards,

Florent.

[fumanchu]

On Feb 6, 12:50 am, "Florent Aide" <florent.a...@gmail.com> wrote:
> The problem is I am not an rfc2616 expert but there seem to be much
> more options and I don't have a clear idea of how to give access to
> all this easily.
>
> The easiest route seems to just give a cache_control parameter and
> then let the user specify this header by himself (not really friendly
> but powerful) and the second route is to provided different arguments
> that help people set an header without having to fully read and
> understand the rfc2616...

First, I find overloading "expose" in this way pretty ugly. Sorry. :/
There has to be a limit on what a single function can do, and this
goes *far* over that line (mostly because that line was crossed long
ago anyway, IMO).

Second, why not take 5 minutes and port cherrypy.lib.caching.expires
from CP 3? Then you'd not only have a nice tool, but a forward-
compatible one to boot.

Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org

[Elvelind Grandin]

I have to agree on Robert on this one.
Expose is too big and complicated as it is. lets not add more to it.

--
cheers
elvelind grandin

[Florent Aide]

On 2/6/07, fumanchu <fuma...@amor.org> wrote:

[...]

> First, I find overloading "expose" in this way pretty ugly. Sorry. :/

No offense taken :) Part of the reason why I posted in this list in
addition to adding the trac ticket is because a small voice in the
back of my mind told me this was some kind of hack and I was pretty
sure CP would have a solution already there.

> There has to be a limit on what a single function can do, and this
> goes *far* over that line (mostly because that line was crossed long
> ago anyway, IMO).

Agreed again.

> Second, why not take 5 minutes and port cherrypy.lib.caching.expires
> from CP 3? Then you'd not only have a nice tool, but a forward-
> compatible one to boot.

I was half expecting you to point me in the right direction and half
expecting to find it by myself when the itch would scratch. You were
quicker.

Thanks for the input. I'll look into this and see what I can do out of it.

Florent.