[opensource-dev] User Story: Improved Cache
kelly at lindenlab.com
Thu Sep 16 09:58:13 PDT 2010
Strictly speaking I think you have the stories and tasks reversed here.
As a user I'd like to be able to use a greater portion of my available disk
to improve the SL experience.
* Task: Improve the cache system to allow larger caches
As a user I'd like the places I visit most often, like my 'home' and
favorites, to load more quickly
* Task: Improve the cache system to not discard data for my home (at least
not for a while)
* Task: Improve the cache system to not discard data for my 'favorites'
places (at least not for a while)
As a user I'd like to never have to clear the cache to fix a bug
* Task: Implement a quick and efficient inventory verification to find
inventory cache discrepancies.
* Task: (Are there other common bugs that require a cache clear to fix?)
Improving the cache system is a task (actually multiple tasks) used to
accomplish the three experience stories you have. Stories should generally
be about the end experience, not the underlying system or how the
experiences will be fixed. Yes, that is a rough guide, especially for many
stories where the actor is 'a developer', but it helps still. :)
That said these are great ideas, and should definitely be on a backlog
somewhere if they aren't. I know we have discussed all of them at one point
On Thu, Sep 16, 2010 at 9:44 AM, Daniel <danielravennest at gmail.com> wrote:
> As a user I would like to see an improved cache in order to have a
> better Second Life experience. The types
> of improvements that would lead to a better experience include:
> * A higher cache size limit. This would let me save more data and speed
> up rez times, and also put less
> load on the server side, since it would not have to refresh discarded
> data as often. Modern hard drives
> are much much larger than the current 1 GB limit, and I should be able
> to allocate more storage to
> my Second Life data if it improves performance.
> * Ability to set certain locations as "home" or "favorites", and to
> never discard or preferentially keep those
> locations in cache. Places I know I will visit often should not be
> discarded just because I happen to visit
> several other locations in the course of a session.
> * More reliability in cache storage, leading to less often need to
> delete cache to fix a problem caused by
> cache corruption. A low level inventory verification (meaning it does
> not take a large percentage of viewer
> resources) to ensure it matches the asset database is an example, but
> technical implementation I will leave
> to programmers. The desired result is less frequent issues like
> apparent inventory loss, which upsets users
> and leads to support tickets.
> Policies and (un)subscribe information available here:
> Please read the policies before posting to keep unmoderated posting
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opensource-dev