re-using the expire time in the header to reset the refresh rate was
also just an idea, which seems logical, but a better approach is perhaps
to replace the text from the <include> up to the </include> include those
two tags. If the included text happens to have a <include refresh = 200>
than that part will refresh after 200 seconds. That seems even cleaner
to me, because no magic is involved, and the included part can be stored
on some caching scheme, because the expire date is really the expire date
and we don't need to overload things.
yet another example of the power of include & refresh is to make
a nice slide show. Just start every page of the show with
<include refresh=15 src="url_of_next_slide"> and end the page with </include>
each page will show for 15 seconds and automaticlly load the next slide.
or
refresh an image taken by a life camera every 2 minutes
or
... use your imagination.
as said before having the client handle this seems feasable with current
technology in the web. The only problem is that browser will need to
reformat the document every time an update occurs
>
>
> Does this really require a REFRESH attribute? It seems that everything
> except the delayed loading would still work if the client only used
> the Expires header of the included document. I can see that delayed
> loading is nice, but in practice I think it would nearly always be
> refresh=0, because it is to much work to keep the expire rate of the
> external doc and the refresh attribute in step and to keep the
> contents of the INCLUDE element coordinated with the contents of the
> external doc.
>
using the above proposal doesn't need the Expires header and the header
still can have Expires in the original meaning (good for caching servers or
caching gateways) The document itself does not expire but the static
document contains a dynamic element . No need to keep th expire header
in sync with the include element.
- frans