[Tickets #12589] Re: Kolab_Storage: Ensure status($folder) is not cached

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12589
------------------------------------------------------------------------------
  Ticket             | 12589
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Kolab_Storage: Ensure status($folder) is not cached
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             | Jan Schneider
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2013-08-23 12:41) wrote:

> Thanks! Please take a look at the change again, I think you  
> accidentally added the wrong flag.
> (STATUS_UIDNEXT_FORCE instead of STATUS_FORCE_REFRESH).

Fixed.

> Hmm, I'm still not sure if this is the ideal solution. As you  
> pointed out earlier,
> this might cause more round trips to the imap server than necessary.

It all depends on your code.

> If we look at the search() function for example, in the "long  
> running script mode"
> it would issue a STATUS command to the server and based on that
> result send a SEARCH command or not. In that case it would be better
> to just send the SEARCH directly.

No, not necessarily.  At worst if would issue a NOOP.  Otherwise, the  
mailbox needs to be opened anyway for the SEARCH command.  Either way,  
the downside is the potential for sending a NOOP as a way to possibly  
prevent opening the mailbox.  The former is MUCH preferred over the  
latter (opening a mailbox is expensive).

> I think for most use-cases of long running scripts, the new
> STATUS_FORCE_REFRESH flag will do the job just fine as the
> library users can decide when to use caching and when not.

But as you pointed out with vanished(), there's places internally  
where we call status().  A library user would otherwise have no  
control over these calls.  There has to be a way to disable caching so  
that this internal calls don't potentially return different data than  
a status() call with an explicit STATUS_FORCE_REFRESH.