On Apr 12, 2006, at 3:42 PM, Fernando Padilla wrote:
right. the issue/goal with 'last-modified' is that calculating
'last-modified' will be cheaper than rebuilding the whole output.
Indeed, just returning a cached rendering of a component can be
valuable, but I'm not sure the last-modified model is the best one
for server-side cache validation. Most operating systems now support
filesystem change notifications; SQL Server 2005 can even notify
clients when a query's results would change. These are fundamentally
"push" models. To support both push and pull, how about something
like this:
public interface Dependency {
boolean isInvalid();
}
void SimpleFileDependency implements Dependency {
File file;
long cachedModificationTime;
public SimpleFileDependency(File file) {
this.file = file;
cachedModificationTime = file.lastModified();
}
public boolean isInvalid() {
return cachedModificationTime != file.lastModified();
}
}
class NotificationFileDependency implements Dependency {
FileChangeNotification notification;
boolean isInvalid;
public NotificationFileDependency(File file) {
notification = new MysicalMagicalFileChangeNotification {
public void fileChanged() {
isInvalid = true;
}
};
}
public boolean isInvalid() {
return isInvalid;
}
public static boolean isSupported() {
magic!
}
}
public class CacheEntry {
...
public void addDependency(File file) {
if (NotificationFileDependency.isSupported())
addDependency(new NotificationFileDependency(file));
else
addDependency(new SimpleFileDependency(file));
}
public void addDependency(Dependency dependency) {
...
}
}
A CacheEntry can easily know when it was generated, and can simply
report that as its modification date for the Last-Modified HTTP
header field. Thus, dependencies don't need to calculate that data.
Generically determining whether something is cacheable in Tapestry
strikes me as harder, though.
— G
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
