Re: Use of 304 - not modified

Clemens Klein-Robbenhaar wrote:

>  Looking at the "toc" inside a Silva Document I feel we need two new
> methods;
> one to get the last modification of the public viewable version
> (the "get_modification_datetime" in ISilvaObject returns the modification
> time of the previewable object, which may be differnt from the public
> viewable object for versioned content).
>  I call the "get_public_modification_datetime" just to have a name
> for this mail.
> 
>  The other one would be the aggregated modification time of the object
> and all its dependencies, and would default to the public modification
> datetime. Hm, I call it "get_overall_public_modification_datetime"

Exactly, there are two important date informations for a page:

If we look at the workflow, a author may save a document, then he calls
for approval. Some time later an editor publishes the document. This is
the 'natural' public modification date, and it is well suited for
documenting the date of the documents textual content itself (ie. for
display in a page footer or the meta informations in the HTTP header).
This would be the information used in a discussion like "when did you
published your research results".

In contrast overall_public_modification_datetime resolves all
dependencies to contained objects, which is of importance for
determination of the freshness of a document. This would be used in a
technical context only, the Last-modified HTTP header.

>  The reason to split this is that if a document contains a toc it has to
> ask
> all listed items if their title has changed. Having a separate "get last
> time
> the title has changed" seem to be overkill, so  I guess the code has
> to call the "get_public_modification_datetime" of the objects.

As the title is part of a documents metadata, and the document must be
published again to activate a new title, this change would be reflected
by the documents own publication date.

On Zope level, the date of a folderish objects changes if its content
changes, so TOC objects could quickly detect the last valid date and
even detect deleted documents (changing the TOC too).

I guess that none of our ten thousands of pages uses the internal TOC
element, as it is not flexible enough (fixed tabular layout; and authors
want language awareness or document hiding, which is implemented in
ETHLayout only), but the principles could be applied to custom TOCs too,
as used as navigation in ETHLayout.

>  The "get_overall_public_modification_datetime" could maybe be implemented
> via some adapter to keep the code away from the main object hierarchy.
> (In my case it has been a monkey patch instead ...).
>  Hm, but maybe it should not. After all the implementation seems to follow
> the inheritance hierarchy quite closely ... e.g. both Folders and
> Publications
> will want to delegate the calculation to their default ...

One thing is the method every object used in building a page should
know: get_public_modification_datetime, which returns the last
modification date of an object (document, document part etc.).

The other thing is a pair of methods/functions that compares a given
date to a stored value and eventually replaces the stored date with a
newer one, or reads the stored date for final use in the HTTP header
Last-modified. This would also hide the implementation how this value
will be stored and allow for further changes.

>  I feel the step of investigating the modification datetime and deciding on
> returning a 304 should be a local customization of the "index_html".

I would separate: the modification to index_html just implements a
detection of the 304 value, if set by whatever method. It's just to stay
compliant to RFC 2068:

"... 304 (not modified) responses MUST NOT include a message-body", so
Silva must return no body if after all processing a 304 occurs (its the
same with all 1xx and the 204 (no content) return codes). The index_html
will not care about who set this code.

>  The reason for this is that the public layout could contain more elements,
> e.g. a news ticker in a sidebar, or just a navigation path,
> and it would be somewhat incorrect to argue that the page has not
> been changed because the content object is not modified in between.
>  I do not know if You want to invalidate all pages just in case
> the title of some content in the navigation tree has changed, but
> I think its better to leave the decision to You as the site admin ;-)

The basic method to collect overall_public_modification_datetime which
will be called by documents and other objects should also be callable
out of customizeable parts like layout_macro/content.html, as outlined
above.

So layout designers can raise the date if needed: if all opaque
components of a page contribute to the overall modification date
transparently, layout designers will happily integrate their own
modification date correction by using a single method to set the date.

If, hopefully somewhere in the future, layout designers can choose out
of a bunch of page building objects (downward navigation aka. TOC,
upward navigation aka. breadcrumb, login and search form etc.) to be
used in layout_macro/content.html, maybe these blocks will be able to
handle all modification date stuff completely by their own (aren't
GARDENS growing mostly in spring time :) )?

Regards

Bengt