"For all community-portals (dotlrn_class, dotlrn_class_instance, dotlrn_club, dotlrn_department) but the user portal i have ripped out the real portal-system and created a "static" version where all portlet are called directly with given parameters (=unchangeable portal layout)."
Now that I've got the rewritten portal system working within OpenACS, my next two goals will be:
1. reintegration with .LRN (of course!)
2. Maximum caching of portal information. In particular parameters to portlets very, very rarely change and all the database operations to set the render call up can be cached more-or-less permanently. Since the parameters should only be changed through portal package API calls caching can be controlled with 100% accuracy unless someone goes out of their way to break the rules, in which case the screw
'em.
"Next important thing will be to enhance the real portal system and to cache portlet content."
Coming up with a useful scheme for this might be tricky, unless we just want to say "cache content for five minutes" or something like that. The problem with any portlet content caching approach implemented by the portal package itself is that portlet content won't match the content you get when you visit the package itself ... very confusing.
On the other hand if we implemented per-application package caching and if portlets share application code properly then they can both be made to render the same content, maybe even coherently if caching's implemented intelligently :)
But one thing is for sure ... portal-level stuff (determining layout, parameters to pass to portlets, etc) can be made to run with zero db hits (after the cache is filled by visitors, of course) without much trouble at all. I've been looking into it ...
