On Fri, Sep 17, 2010 at 9:56 AM, Ponzu <lee.po...@gmail.com> wrote: > But some users want to be able to override this. I want a certain > location to always load fast, even if I rarely visit it. > > User story: I want to mark certain locations as "Fast Loading" even > if I do not visit them very often. This should override the automatic > behavior of the system. > > A passive means of ranking a cache would be:
1) did the user already have an LM here? 2) did an object just give a user an LM to this place? 3) did the user just proactively create an LM? These are 3 distinct cases. #1 and #3 imply that the user has an interest in coming back, and is likely to want an ongoing cache. #2 implies that a store / venue etc may have given the user an LM they didn't want. Another case is: if a user deletes an LM, it implies they may want to free up the cache for that location as well. Daniel > On Fri, Sep 17, 2010 at 11:42 AM, Marc Adored <m...@inworlddesigns.com> > wrote: > > I think that maybe "places" should have scores of how often they are > > visted to determine how long the cache of that place is stored. So > > since every login you start at home it would have a high score > > therefore the cache would be stored for a longer period of time. Same > > goes for places you visit often. This would remove any interaction > > needed by the user because the system would pretty much auto detect > > what places you would have as a favorite... > > > > On Thu, Sep 16, 2010 at 12:58 PM, Kelly Linden <ke...@lindenlab.com> > wrote: > >> 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 > >> or another. > >> > >> - Kelly > >> > >> On Thu, Sep 16, 2010 at 9:44 AM, Daniel <danielravenn...@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: > >>> http://wiki.secondlife.com/wiki/OpenSource-Dev > >>> Please read the policies before posting to keep unmoderated posting > >>> privileges > >> > >> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/OpenSource-Dev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > >> > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -- Daniel Smith - Sonoma County, California http://daniel.org/resume
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
