Hi Rob, thank you for this. Once again you've thought of things that I haven't so your input is very valuable whenever it comes...though sorry if you've had to say it twice; I promise not to forget this time.
We (that's Graham and a couple of others) are going to get together here tomorrow to have a look at what I have done so far and I will make sure we talk through: 1. an ini option to turn off caching - a must-have for shared hosting 2. per-request caching - I wasn't doing this yet but a definite possibility - just need to work out when it pays off 3. file-based caching What I really want to know is .... what is the meaning of the smiley :/ I keep looking at it and keep seeing it as a frog with its tongue out :) Matthew On Apr 10, 7:44 pm, "Rob" <[EMAIL PROTECTED]> wrote: > 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 firstname.lastname@example.org 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 -~----------~----~----~----~------~----~------~--~---