[Phpslash-devel] Re: [Back-end-development] Re: jpcache - thoughts

[Mike G. <mi...@op...>]

Howdy,

On Tue, 2002-11-12 at 10:57, Peter Cruickshank wrote:
> At 17:36 09/11/02 -0500, Mike Gifford wrote:
> >On Thu, 2002-11-07 at 14:15, Joe Stewart wrote:
> >> On Thu, Nov 07, 2002 at 07:07:59PM +0000, Peter Cruickshank wrote:
> >> > I didnt reply to Joe because I've not played around with jpcache, but here are my thoughts on 
> >> > caching for BE/PSL....
> >I've played around with jpcache & am running Linux here on my desktop so
> >can modify whatever I like (assuming it doesn't take me too long to put
> >it all back)..
> Using jpcache might be the time to change BE's minimum requirement to PHP4.1 - that way, we can use jpcache2 and be sure of keeping up with bugfixes etc

I would agree with this..  Many of the distributions seem to be jumping
to at least PHP4.1 due to discovered security concerns..  

Mind you some hosts don't worry too much about staying up with these
security patches..

<snip>

> Thinks out loud: I wonder if the block-level caching class could use jpcache 
> functions for building keys and saving data (to file or db)? (It's interesting 
> to see that jpcache has a two-key approach: one based on the php filename 
> (jpcache_scriptkey), and the other on the GET, POST (and optionally COOKIE) values 
> (jpcache_varkey - would need adapted to only use the vars that are relevant to the 
> individual block). The advantage would be that only one cache DB table or directory 
> would be needed.... I think I need to keep on thinking though :-)

Sounds like an interesting approach for sure!  Not sure what the
resource implications of this would be but it would sure make it easier
to add new cache files and link it into the block format so that it can
be as user defined as the blocks are now (without requiring db
modifications).  I would think that it would be worth while putting
these blocks in a subdirectory of the main cache directory.

> > > I do like the niceties that jpache has for full page caching though - 
> >> gzip, ETags ( 304's), etc.
> >I wouldn't think it would be necessary/useful to recreate what jpcache
> >has done..  I would think that upcoming releases of Back-End will just
> >have jpcache set up with the default install
> What are the implications for activity logging of using jpcache? 
> How will you know what articles are popular? Might need to stick some 
> pre-processing into the head of the pages before jumping to jpcache.

I had this concern as well.  It is possible to move up the counter
applications before jpcache is used.  This is probably a good solution
in the long term.  However, for the moment (least when we decide to
release it), I think it would be safe to say that the hit counter is
only an indication of the use of the site and during periods of high use
it does not accurately reflect the hits to the site (standard log
analysis is still required)..

In the future it would be useful to allow a bit more sophisticated user
tracking..  Would be nice if spiders weren't counted the same as
eyeballs (you want to know when googlebot was last on the the site, but
don't want to confuse that with someone actually reading the page).. 
Would also be interesting to know how people navigate through the site. 
This is all possible to track..  Would be nice if someone else has
already developed the code though (so we could just incorporate it)

Mike
-- 
Mike Gifford <mi...@op...>
OpenConcept Consulting