Hi all, i probably want to do something that isnt going to work well
anyways, but maybe someone has a good idea.
Through the api (message_headers_output) im adding a button next to
the address-add button on the From line. This second button adds the
sender to a centralized whitelist. To be nice, I want to remove the
button immediately after clicking, and thats all working fine. Just a
bit of JS to remove the button.
If a user is already in the whitelist (which i load on login_after), i
dont add the button, and if you click on the button I make sure the
whitelist is reloaded so future emails of this same sender dont get
the button either.
Im running into a little problem. message_headers_output is not always
called. If I read the next email, then go back to the previous email
where I just clicked the button (which was removed), the button re-
appears. This is not due to anything wrong with the plugin code, but
because RC sends Etags and If-Modified headers which my browser
happily uses to show me a cached version of the previous header.
Im assuming this is wanted behavior. The more caching the better I
guess, but in this case its biting me. Is there anyway I can prevent
this from happening? Or should I just give up on trying to show the
right thing?
(the same can be said for the addressbook-add button.. why show it if
you're already in the addressbook).
Any tips appreciated,
Cor _______________________________________________ List info: http://lists.roundcube.net/dev/
On Thu, May 28, 2009 at 14:07, Cor Bosman cor@xs4all.nl wrote:
Im running into a little problem. message_headers_output is not always called. If I read the next email, then go back to the previous email where I just clicked the button (which was removed), the button re- appears. This is not due to anything wrong with the plugin code, but because RC sends Etags and If-Modified headers which my browser happily uses to show me a cached version of the previous header.
Im assuming this is wanted behavior. The more caching the better I guess, but in this case its biting me. Is there anyway I can prevent this from happening? Or should I just give up on trying to show the right thing?
Looks like we have to add another hook to manipulate the caching of message views.
(the same can be said for the addressbook-add button.. why show it if you're already in the addressbook).
You're absolutely right...
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.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Thomas Bruederli wrote:
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.
BTW, there are other ugly bugs related to etags.
http://trac.roundcube.net/ticket/1485623
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
List info: http://lists.roundcube.net/dev/
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/
Just curious, but why need a hook for the etag, when technically, we could "fix" it for everyone? I wouldn't go hook crazy.
Fix it how? Any way is fine with me :)
Cor
List info: http://lists.roundcube.net/dev/
On May 29, 2009, at 1:29 PM, Cor Bosman wrote:
Looks like we have to add another hook to manipulate the caching of message views.
I solved my own problem by just changing the $_REQUEST headers so RC
cant match the etags. This works for me. In general though, I think
people may need a way to prevent caching on certain uids.
Cor _______________________________________________ List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Cor Bosman -
Thomas Bruederli -
till