Comment 3 for bug 614005

2010/8/6 Roland Hedberg <email address hidden>:
> On 8/6/10 17:22, Roland Hedberg wrote:
>> On 8/5/10 22:09, Lorenzo Gil Sanchez wrote:
>>
>>> Public bug reported:
>>>
>>> Right now, when you instantiate a Client object it accept a
>>> persistent_cache argument. This is used to create a Population object
>>> which will use it to create a Cache object. When the argument reach this
>>> point the cache is either stored in a file or not persisted at all.
>>>
>>> This cache thing is neccesary to perform the logout since this is the
>>> link in pysaml2 between a session initiated in the authenticate step and
>>> the logout process. But my problem is that being a file is not very
>>> efficient or robust when you have an SP used concurrently by a lot of
>>> users. How are the concurrent accesses to the cache file handled?
>>>
>>> I would prefer to store that information in other places like a Memcache
>>> server. So if I instantiate a Client object and pass a persistent_cache
>>> object different than None, it should be treated as a Cache object and
>>> not as a filename or something like this.
>>>
>>>
>> Good idea !
>>
>> So, we only have to decide which functionality a Cache object
>> should/must implement
>>
> The interface is defined in cache.py .
> I change the code to accept None in which case it will be a
> non-persistent storage or a pointer to an object that adheres to the
> Cache interface.
>

Great, I think that way is so much more flexible and useful. I'll
probably write two implementations of the Cache interface: one that
save the stuff in a database table and another one that uses a
Memcached server. I'll let the user to choose which one he wants to
use via a Django settings preference.