[Savannah-hackers] [ 102089 ] SSI for timestamps

[nobody]

Support Request #102089, was updated on Mon 04/28/03 at 14:42
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=102089&group_id=11

Category: Web
Status: Open
Priority: 3
Summary: SSI for timestamps

By: yeupou
Date: Mon 04/28/03 at 20:14
Logged In: YES 
user_id=1896
Browser: Mozilla/5.0 (compatible; Konqueror/3.1; Linux 2.4.21-pre7-ac2; i686; 
fr, address@hidden)

I assign this request to Paul Fischer from system-hackers that usually 
take care of the webserver. 
 
Maybe he can propose you a better solution or provide SSI 

----------------------------------------------------------------------

By: humppake
Date: Mon 04/28/03 at 19:10
Logged In: YES 
user_id=9471
Browser: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

It's unfortunate that SSI is not as easily available as we
thought, but I suppose we should just live with that. Yes,
we did think also the alternatives, but because tools like
SSI have been developed "to make things easier", why
wouldn't even try to use them.

>"Not generating files until their correspondant
>RST change. This way you can use cvs $Id: $
>without bothering."

This looks like the way it should be done, but... at first,
this won't work with $Id:$ tags. The problem is that after
converting RSTs (which stands for reStcurturedText) into
HTML we embed the navigation menu into every page as
postprocessing the HTML. Now the file is technically changed
and also CVS stamps change. We would like that timestamps
mark date of the main content - not menus.

No, we don't want to use frames.

The second best solution for now is to combine those two
solution you also suggested. We should let the RST -> HTML
embed a timestamp into HTML (fetching the $ID:$ from the RST
is a good idea, but we can't trust that it's always
remebered to put there), but we should not make the
conversion again until RST is changed. Menus could be
updated without touching the written timestamp. 

But how to do that... well, of course, it's our problem. CVS
update seem to change files' datestamp, which is usually
good for working with Make, but now it causes unwanted
reconversion of updated file. Checkouting shouldn't be the
only way to update :)

Though, we probably can't use Make that way (calling
converter for single changed files) anyway, because 
with our current conventions it would cost too much time.
That's because we run the RST -> HTML converter through
JAR-packed Jython and that has a terrible start-up time.

...

Ok. Will do it ugly way (which looked "too complicated" at
first): checking if already converted version exist and
fetching the old $ID:$ tag into new one. If the RST content
hasn't changed, neither has the resulted HTML conversion and
CVS shouldn't commit it.

Anyway, Thanks for your time :)

----------------------------------------------------------------------
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=102089&group_id=11