[Openstreetmap-dev] Re: [Openstreetmap] cache of editor applet background?

Erik Johansson erjohan at gmail.com
Tue Jan 24 10:11:26 GMT 2006


On 1/24/06, Mikel Maron <mikel_maron at yahoo.com> wrote:
>
> > Squids cache can be invalidated/purged with the squidclient command,
> > it is available in the squid source package  (or in debian by: apt-get
> > install squidclient). I've also seen a perl script called Cache
> > Purger, which works by allowing you to search for specific URLs that
> > you want to invalidate.
>
> Yes, this was my intention. The logic of Tom's javascript code would be rewritten in a Ruby script,
> with care to make sure the Math produced tiles with the same bbox prevision. From all the recently
> added points, determine all the invalidated tiles, and run one of the command line tools with this list.
>
> > But, Instead we should solve the problem; dao.rb should have a
> > get_[node|gpxpoint|segment]_etag(bbx) method, that allows us to
> > compute an etag. This would allow us to send an ETag on the image we
> > want to send  and then parse "If-None-Match: ETAG-ETAG-ETAG1" type
> > headers that the client sends. If the ETag matches the current one we
> > can  send a header with a 304 response code to indicate that nothing
> > has changed.
>
> This would be another way to do it. But it would add unneeded complexity on the client? And overhead with
> ETAG generation and requests.

Short answer no. It is a way to help *Squid* now when to cache
something, That means squid should ask if the page has been updated or
not, before downloading it. I don't know the configuration options for
this in squid, or how it handles it. It should work by default, since
it's a vital part of caching.

Only way to now is to test.

Of course you could add support for ETags/If-modified-since in the
applet, but this would be necessary only if you will save images
localy in some way (cache).

Finnally if you could get mapserver to produce such tags on the
composed image for the slippy map interface it would probably help as
well.

--
/Erik




More information about the dev mailing list