launchpad development
DRAFT: Invalidating Page Snippets
The current TALES support for memcached does not support invalidation when the data changes, relying on timed expiration instead. Invalidation would be preferable for users, particularly when users want to see the results of their own work (see 593054). Invalidations from scripts and other work done outside of the application are not as important for this case.
As a Launchpad User
I want fast-rendering Launchpad pages that immediately reflect my actions
so that I'm not confused by some parts of Launchpad seeming to not be affected by changes I have made.
Invalidations are tricky, as we expected and then explored in the webservice work.
Rationale
Cached page snippets have proved to give us benefit, thanks to our current TALES implementation. However, even before we have significantly deployed them, we are getting bugs about user confusion.
Moreover, the current design does not clearly enforce a page structure that encourages safe cacheing. This is an advantage for testing and easy deployment, but often getting good cacheing characteristics will involve refactoring the page anyway.
Stakeholders
Launchpad users.
Constraints
What MUST the new behaviour provide?
What MUST it not do?
Unnecessary Desires
What are ideas that might be desirable, but are *not* constraints for this proposal?
Success
How will we know when we are done?
How will we measure how well we have done?
Subfeatures
OPTIONAL
Other LaunchpadEnhancementProposals that form a part of this one.
Implementation Proposal
Description
How will this work?
Workflows
OPTIONAL
What are the workflows for this feature? Provide mockups for each workflow.
You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.
Risks
What are the risks associated with this implementation? Consider risks that may make the implementation fail to meet its goals, risks that may make the delivery time slip, security risks, performance risks, and usability/documentation risks.
Experiment 1
It will often be appropriate to construct one or more experiments to address the identified risks before proceeding to the implementation step. Make sure that the effort to construct experiments is significantly less than the effort expected to be expended on the implementation!
Goal
What is the goal of the experiment? What risk or risks do you intend to explore?
Design
How will the experiment work?
Result
How did it turn out?
Thoughts?
Put everything else here.
