On Fri, May 29, 2009 at 1:29 PM, Cor Bosman cor@xs4all.nl wrote:
Looks like we have to add another hook to manipulate the caching of message views.
Any tips appreciated,
You can try to implement a plugin hook in program/steps/mail/show.inc where the etag is composed. Either the hook can manipulate/replace the hashing function that creates the etag or it just returns true/false to enable/disable caching at all. I'm not sure which approach would fit best.
I tested it like this. I added a hook above the etag creation line in show.inc. That hook allows me to modify the etag like this:
// calculate Etag for this request $etag = md5($MESSAGE->uid.$mbox_name.session_id() .(isset($data['modifier']) ? $data['modifier'] : '') <--------- .intval($MESSAGE->headers->mdn_sent) .intval($MESSAGE->is_safe) .(!empty($MESSAGE->attachments) ? intval($CONFIG['inline_images']) : '') .intval($PRINT_MODE));
In my plugin I keep track of the uids of which I change the header, and if the currently viewed uid is in that list, I return a modifier for the etag. The etag changes, and my browser doesnt show me a cached version but grabs a new one. I then remove the uid from the list, so a next view returns the etag value to the original value, but by then my browser has the new data.
But, im thinking. I can probably do this without the hook. I can hook into an early hook like 'message_load', and then change the $_REQUEST etag. The code wont be able to match them and return a fresh version. Kinda ugly, but it works.
Anyways, im not sure whats best. If you can add a hook near the $etag creation in show.inc that would be very welcome. I wasnt sure what data one would want to have inside the plugin. Im currently just passing $MESSAGE->uid, but maybe all of $MESSAGE would be handy.
Cor
Just curious, but why need a hook for the etag, when technically, we could "fix" it for everyone? I wouldn't go hook crazy.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/