[Zope-dev] [Checkins] SVN: zope.app.publisher/trunk/ To make browsers update their caches of resources immediately when the

[Benji York]

On Wed, Jun 10, 2009 at 3:51 AM, Christian Zagrodnick<cz at gocept.com> wrote:
>
> The checkin actually is two in one (which aruably is not such a good thing):
>
> 1. Make resources compute urls with an IAbsoluteURL adapter so they
> behave like every other object.
>
> 2. Provide an optional hashing adapter (and the ++noop++ namespace).

I'd actually separate number 2 into 2a (hashing adapter) and 2b
(++noop++ namespace).

> I don't think we have to argue about 1.

Agreed.

> The ++noop++ and hashing could easily be moved to a different package.

I'd like to use the ++noop++ functionality separately from the hash
calculating URL generation.

> The idea behind the hasing is that one should not have to think about
> new versions or cache invalidations. That's also why in development
> mode the hash is computed every time and not just once: It aids
> development a lot. But it helps in deployment as well of course.

In my apps, I'll likely store a unique ID for each resource, or even use
(a variation of) the app's version number for resources.  That's why I'd
like to use the ++noop++ namespace without the URL generation policy.

> So, why in a zope package? Because I really think this is a core issue
> of a web framework. Do we really want to not change any zope.* package
> any more in regard to new features?

It is a core issue, but I'm not sure we've decided how to handle it yet.
I'd rather the community try a few things and see if one dominant
approach emerges.  If so, it can be promoted to the zope namespace.  Or
not, there's no reason all widely used packages have to be in zope.*.
-- 
Benji York
Senior Software Engineer
Zope Corporation