Mailing List Archive: Zope: Dev

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

Index | Next | Previous | View Threaded

srichter at cosmos

Jun 9, 2009, 6:51 AM

Post #1 of 6 (486 views)
Permalink

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

On Tuesday 09 June 2009, Wolfgang Schnerring wrote:
> To make browsers update their caches of resources immediately when the
> resource changes, the absolute URLs of resources can now be made to
> contain a hash of the resource's contents, so it will look like
> /++noop++12345/@@/myresource instead of /@@/myresource.
>
> - Implemented an AbsoluteURL adapter that computes a hash of the
> resource's contents and inserts that into the URL. - Content hashes will be
> cached in memory, except when in developer mode - Introduced a ++noop++
> traverser that simply throws away the path segment - Wrote a bit of
> documentation about resources

Mmmh, this looks like a lot of extra code to get behavior that is served
better with different tools. Have you looked at z3c.versionedresource and
z3c.traverser? Both of those should solve these type of use cases well.

Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

dev at projekt01

Jun 9, 2009, 7:50 AM

Post #2 of 6 (447 views)
Permalink

Re: [Checkins] SVN: zope.app.publisher/trunk/ To makebrowsers update their caches of resources immediately when the [In reply to]

Hi all

> Betreff: Re: [Zope-dev] [Checkins] SVN:
> zope.app.publisher/trunk/ To makebrowsers update their caches
> of resources immediately when the
>
> On Tuesday 09 June 2009, Wolfgang Schnerring wrote:
> > To make browsers update their caches of resources
> immediately when
> > the
> > resource changes, the absolute URLs of resources can now
> be made to
> > contain a hash of the resource's contents, so it will look like
> > /++noop++12345/@@/myresource instead of /@@/myresource.
> >
> > - Implemented an AbsoluteURL adapter that computes a hash of the
> > resource's contents and inserts that into the URL. - Content hashes
> > will be cached in memory, except when in developer mode -
> Introduced a
> > ++noop++ traverser that simply throws away the path segment
> - Wrote a
> > bit of documentation about resources
>
> Mmmh, this looks like a lot of extra code to get behavior
> that is served better with different tools. Have you looked
> at z3c.versionedresource and z3c.traverser? Both of those
> should solve these type of use cases well.

Serving resources from a Zope server and caching them for
speedup is not the best pattern. I recommend to use a
content delivery network concept and off load the resource
traffic from zope at all.

And as stephan suggested, using the same name for a changed
resource is a bad thing. This implementation seems to me like
a workarround for serving the same url for changed resources.
I also recommend to use different resource names for different
resource versions. z3c.versionedresource offers such a concept.

anyway, I whould be happy if we do not implement such high
level feature in zope core packages. Because there are
1000 different concepts to do it right. Why did you not use
an additional package?

Regards
Roger Ineichen

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

benji at zope

Jun 9, 2009, 7:56 AM

Post #3 of 6 (447 views)
Permalink

Re: [Checkins] SVN: zope.app.publisher/trunk/ To makebrowsers update their caches of resources immediately when the [In reply to]

On Tue, Jun 9, 2009 at 10:50 AM, Roger Ineichen<dev[at]projekt01.ch> wrote:
> anyway, I whould be happy if we do not implement such high
> level feature in zope core packages. Because there are
> 1000 different concepts to do it right. Why did you not use
> an additional package?

I like the idea of ++noop++, but would also like to see it in a z3c (or
similar) package.
--
Benji York
Senior Software Engineer
Zope Corporation
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

cz at gocept

Jun 10, 2009, 12:51 AM

Post #4 of 6 (439 views)
Permalink

Re: [Checkins] SVN: zope.app.publisher/trunk/ To make browsers update their caches of resources immediately when the [In reply to]

Hoi,

On 2009-06-09 15:51:03 +0200, Stephan Richter
<srichter[at]cosmos.phy.tufts.edu> said:

> On Tuesday 09 June 2009, Wolfgang Schnerring wrote:
>> To make browsers update their caches of resources immediately when the
>> resource changes, the absolute URLs of resources can now be made to
>> contain a hash of the resource's contents, so it will look like
>> /++noop++12345/@@/myresource instead of /@@/myresource.
>>
>> - Implemented an AbsoluteURL adapter that computes a hash of the
>> resource's contents and inserts that into the URL. - Content hashes will
> be
>> cached in memory, except when in developer mode - Introduced a ++noop++
>> traverser that simply throws away the path segment - Wrote a bit of
>> documentation about resources
>
> Mmmh, this looks like a lot of extra code to get behavior that is served
>
> better with different tools. Have you looked at z3c.versionedresource and
>
> z3c.traverser? Both of those should solve these type of use cases well.

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 don't think we have to argue about 1.

The ++noop++ and hashing could easily be moved to a different package.
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.

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?

Regards,
--
Christian Zagrodnick · cz[at]gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

ws at gocept

Jun 10, 2009, 1:08 AM

Post #5 of 6 (439 views)
Permalink

Re: ZTK scope (was: [Checkins] SVN: zope.app.publisher/trunk/) [In reply to]

Hello,

* Stephan Richter <srichter[at]cosmos.phy.tufts.edu> [2009-06-09 15:51]:
> On Tuesday 09 June 2009, Wolfgang Schnerring wrote:
>> To make browsers update their caches of resources immediately when the
>> resource changes, the absolute URLs of resources can now be made to
>> contain a hash of the resource's contents, so it will look like
>> /++noop++12345/@@/myresource instead of /@@/myresource.
>
> Mmmh, this looks like a lot of extra code to get behavior that is served
> better with different tools. Have you looked at z3c.versionedresource and
> z3c.traverser? Both of those should solve these type of use cases well.

Hmm, it looks like z3c.versionedresource requires me to use a
non-standard way to retrieve a resource's URL, which is a major
requirement for me; and I must confess I'm not sure how z3c.traverser
would help me implement this functionality.

I do feel that this incident touches upon a quite important point, and that
is the scope of the Zope Toolkit. As I understand it, the ZTK wants to
provide support for developing web applications. To do that, I think it
should provide solutions to common problems in that area. Browser caches
and CSS/JS-files IMHO is a common problem that is well within the scope
of the ZTK, and so we should have a ready-to-use solution there.

But sure, this functionality can be moved outside of zope.app.publisher,
since with r100748 Resource uses IAbsoluteURL, which can be customized
externally, so I'll back out the change for the time being.

Wolfgang

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

benji at zope

Jun 10, 2009, 4:27 AM

Post #6 of 6 (440 views)
Permalink

Re: [Checkins] SVN: zope.app.publisher/trunk/ To make browsers update their caches of resources immediately when the [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com