Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#9 PHP Session caching (heavy modification of magpie)

Chris Thomas


I was attempting to get magpie rss to work on my
sourceforge homepage for a
project of mine and I couldnt figure out why it wouldnt
work, I found out
eventually that sourceforge mount the project website
directories as read
only, which meant I couldnt use the magpie caching
feature to prevent people
from getting pissed at me for bashing their feeds a lot.

so I was thinking and I came up with a stop gap
solution which can be
further developed, but I thought i would put the idea
and patch out there
now and maybe someone else can advise or help or whatever.

basically todo this I had to modify the following files:

this file directly accesses the RSSCache's ERROR
variable, since I didnt
want to change magpie too much at this stage, I opted
for hiding cache
storage mechanisms behind the RSSCache class, so as far
as everyone else is
concerned, it works identical, albeit not true. I had
to add a get_error()
function to RSSCache to abstract away where RSSCache's
ERROR was truely
coming from.

took to it a chainsaw i did, basically it's a shell for
the storage
mechanisms now, you call cache->set() and internally,
it's called
cache->store->set(), like I said, I know i can update
this further, but I
wanted minimal changes, the simpler the better and the
simpler the more
likely you guys are to accepting the change as a good
thing, if I came back
with a totally rewritten app, you'd most likely say
that you'd want me to
come to your earlier, so here I am :) (NEW FILE)

this is the base class for all cachestore mechanisms,
in the future, maybe a
database cache store, it basically contains variables
that are shared across
many cache stores and the
serialize/unserialize/error/debug code from
rss_cache (NEW FILE)

this is basically the file handling code from
rss_cache, just in a different
place, hardly any alterations to it, perhaps some
variable name changes,
nothing critical and nothing i wouldnt lose any sleep
over changing back if
requested (I hope request is before demanded =] ) (NEW FILE)

this is the sesson store class (figured that out i hope
dammit) it is almost
identical in operation to the file store, except of
storing into a filename,
it stores into a session variable

the obvious comes about here, like trying to store a
100MB feed into a
session variable, before this is production ready,
limits are going to have
to be placed on what you can do with this new layout,
like refusing to cache
anything over 100KB for example, this would cater for a
LOT OF FEEDS without
any hassle, letting most people who want to session
cache feeds without any
trouble, whilst forcing those with larger feeds to look
elsewhere, there are
currently no limits on the size of the feed it'll
attempt to session cache

but I guess that'll be what I do when i put down this email

another obvious issue here, RSSCache takes a parameter
called $base, I'm
thinking that should be, as it is with FileStore the
location of where
magpie stores it's session caches, hence I'm just using

$_SESSION['magpie'][md5] = serialized_data; to store
the data, it should
probably use $_SESSION[$base] instead, kinda like
choosing which array
prefix to use, in case of collisions perhaps?

the timestamp for cache aging is stored in a separate
array position

$_SESSION['magpie'][md5.'_timestamp'] = time();

is what I'm doing right now, if you have any betters
ideas come forward, I
wasnt sure what to do here except for this, I'm sure
it's not the best idea


Thats it

I hope people take to it kindly and don't just rip it
up or trash it, if
you've got something similar in the works, I'd like to
hear about it, the
patches I make are always against the CVS, so I'm sure
someone can take a
look and apply somethig from here and get it to work
like it does for me

chris thomas


  • Chris Thomas
    Chris Thomas

    put into magpierss directory, patch -p1 < patchname.diff