Re: Cache checking on the Node Process step (STEP 2)

Igor Vylusko wrote:
> JCM> Because it depends on what are your "seeds", that are the values on
> JCM> which your output depends. If you need to read something in db depending
> JCM> on a param received by GET, you cannot test for caching being you read
> JCM> your values.
> 
> This "seeds" check may be performed on process step(before DB and other
> operations). Isn't it?
> May be there where some more deep reasons and/or issues to don't do it?

Yes, right, if seeds are not retrieved from db. For a wiki for instance, 
you use GET params to retrieve the data from db, then you know when it 
was changed (mtime field) and you can use cache ;-)
Seems quite stupid...

>>>Also, a have find out that no persistent db connection used all over
>>>in binarycloud(Auth, Perm, ...), although there is persistent property in dataset
>>>config of skeleton package.
> 
> JCM> Persistent connection in php is not always recommended. In some cases, a
> JCM> persistent connection leads to bugs. Maybe it's a param to add to
> JCM> Datasources.conf: persistent boolean default true.
> 
> This param is already included/implied to Datasources.conf but not used at all in
> binarycloud code. Creole getConnection function is called only with one
> parameter (dns) and second parameter(flags) is omitted, thus existing
> binarycloud code doesn't not support persistent connections.

Can someone answer to this ? I cannot :(

> I talk about project properties
>     <property name="Cache-Control">no-store, no-cache, must-revalidate, pre-check=0, post-check=0, max-age=0</property>
>     <property name="Pragma">no-cache</property>
> Can I change this for particular page/node? What is the native way and
> request processing step to do it?

True, I don't know how to do this now.

> I think, the first performance tip is to don't make appliction do
> unnecessary job i.e. to cache(with appropriate settings) all that
> _may_(permited/allowed) be cached on the all app/client levels.
> 
> The second one is inference of preceding - DB connect/disconnect on
> every request is unnecessary app/dbs job i.e. DB connections should be
> cached too.

Right. See other threads about caching conf and strings. We are open to 
more suggestion on this chapter.

> What engine Binaricloud site is powered by?

Smarty for tpl and tpl cache.

-- 
Jean-Christophe Michel