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
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
I keep looking at it and keep seeing it as a frog with its tongue
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
> 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 :)
> On 3 Apr, 11:12, "Matthew Peters" <[EMAIL PROTECTED]>
> > 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
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