[dev] [commits] Horde branch master updated. 37c8d463e562956f6a8f360bcd2cb64a82dd8fea

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting "Michael J. Rubinsky" <mrubinsk at horde.org>:
>>
>>> commit 37c8d463e562956f6a8f360bcd2cb64a82dd8fea
>>> Author: Michael J Rubinsky <mrubinsk at horde.org>
>>> Date:   Mon May 20 11:36:02 2013 -0400
>>>
>>>   Fix history access when no hash table is configured.
>>>
>>>   The injector throws an exception when attempting to get a hash table
>>>   object when one has not been configured.
>>>
>>> framework/Core/lib/Horde/Core/Factory/History.php |   10 ++++++----
>>> 1 files changed, 6 insertions(+), 4 deletions(-)
>>
>> Wondering if we should default to the memory-based hashtable?  Only  
>> downside is that this may slightly increase memory usage for an  
>> access that the admin can't do anything about.  (However, given  
>> size of data in hashtable, this should not be a realistic issue).
>>
>> Otherwise, we could also default to a null hashtable.  We would  
>> incur a bit of a performance penalty anytime we try to retrieve  
>> something from the table, but from a coding perspective this is a  
>> very clean abstraction.
>
> This doesn't make any sense to me. Why bother to keep history  
> information in the memory if it's gone at the next request anyway?

Because the current page could potentially make use of it.  Unlikely,  
maybe.  But not impossible (and, IIRC, at least one page DOES do this).

The same reason we now cache IMAP results in memory for that access  
only if a "real" caching backend is not configured.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]