Yes, exactly right. The scope is intended to be module init to shutdown, and across all callers. I don't really know how I could do otherwise - a per-request cache would be throwing away all the benefit.
Of course you have worried me now. If the keys are chosen poorly - for example every call chooses key "my_first_key" or suchlike - then that is a recipe for disaster. The key needs to correspond to the set of types that are loaded into that DAS: the keys must be chosen so that if the model is different, so is the key. I can't enforce that, of course, all I can do is use it that way throughout the SCA code. On Mar 23, 1:52 pm, "cem" <[EMAIL PROTECTED]> wrote: > This discussion thread hasn't explicitly spelled out the scope of the > cache, but I've been assuming that we're intending it to endure from > module init to module shutdown. In other words, depending on the SAPI, > the cache entries may be available to multiple independent SCA > programs, sequentially and simultaneously. > > Did I get this wrong? I can see how the interface you describe would > work for a request-scoped or possibly thread-scoped cache. But it > doesn't feel right to me to hand out the task of key management to > uncoordinated applications. Imagine if everyone used the same key > string that's in the example code snippet :-) Please put me right. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
