[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 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.
>
> Caching is different because the content can be retrieved when the  
> cache is no longer available. History information is supposed to be  
> persistent, and even it may make sense in one certain situation, it  
> could be very confusing if users see history information at one  
> moment, while it's gone in the next.

This is a problem in abstraction then.  I have no doubt that an in  
memory Horde_HashTable cache is correct as a default memory since  
*most* code will benefit from caching, even if it is for the access  
only.  History caching is the obvious outlier here.

The correct way to handle this in abstraction is to add output from  
Horde_Hashtable as to whether it is "persistent" or not.  But this is  
hackish in its own right.  And if we eventually switch Horde_Hashtable  
to Horde_Cache for the history driver, that doesn't help much either.

The only way I can see of currently/sanely handling this is by  
explicitly switching from the HashTable memory -> null driver in the  
History factory.  Which is also hackish, but of minimal invasiveness  
and self-contained in a single location.

michael


___________________________________
Michael Slusarz [slusarz at horde.org]