Comment 4 for bug 614005

On 8/6/10 19:47, Lorenzo Gil Sanchez wrote:
> 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.
Totally agree !
> 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.
>
Would you mind if we put those in the main pysaml2 branch.
I should give you access to the main branch, will do when I find out how.

-- Roland