Sorry all that I am really late in this conversation (only a few weeks behind). Been meaning to respond but always get distracted by something (think I got ADD or something) :/. I think I had mentioned this before but I really think there needs to be 2 (at least) modes to this. In my case, our company controls the servers, so I would want to be able to set my own key to be used for caching. If other apps/departs want to use my schemas I would share the key with them and everyone would use the same.
This really wont work in the shared hosting environment though. I bet in almost all those cases the hosting provider would not want caching enabled (otherwise not install the extension). They dont want one customer hogging memory here. In this case the per request caching might be applicable (if you are even considering this type of caching). So in short, it would be nice for at the minimum of system caching (shared between processes) and an option to disable completely. Nice to haves would be option for per request or file based caching like ext.soap. I know I just asked for everything here but at the minimum a way to disable caching on a server level (ini option) is definitely needed. Hope I am not too far behind and mentioning things already implemented :) Rob On 3 Apr, 11:12, "Matthew Peters" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
