[Seaside] page caching

Jason Johnson jbjohns at libsource.com
Thu Jul 19 15:27:58 UTC 2007

Ramiro Diaz Trepat wrote:
> Caching would be a real nice thing to have in Seaside.  I believe in
> the feature it would be great if Seaside would not be as closed to
> this completely dynamic model and some ordinary RESTful urls could be
> added to your application, it could come in very handy.  But for now,
> I think is almost impossible to do any page caching.
> It is a shame since in any large web site there are probably lots of
> sections that change seldom and that are identical for all users,
> saying that Seaside should not be used in those cases is also not a
> good answer for me.
> The good news is that probably a big bottleneck on web apps is the
> access to the database, more than the Seaside HTML generation.  So if
> you want to cache those, it could be a good idea.  I was thinking on
> implementing the Squeak client for memcached, and using it to cache
> and distribute persistent data across multiple images / servers.

IMO, page caching is more relevant when you are doing static 
translations from one format to another.  For example, if you have a 
site that stores everything in some XML format, and you want to use XSLT 
or something to translate it to HTML.  That would be a great candidate 
for caching since the translation is expensive and returns the same 
results every time for a given source document.

But most Seaside apps are views of real/live objects.  So to cache that 
would amount to creating a string of all the objects instance variable 
values for your hash key (e.g. an MD5 string).  Something like that 
could done automatically with a clever enough frame work, but the 
question is: would it be worth it to create such machinery?  Has anyone 
actually hit a render bottleneck yet?  Last I heard the encoding and 
socket writing was taking up all the time.

More information about the Seaside mailing list