Closed
Bug 414661
Opened 17 years ago
Closed 17 years ago
bypass caching by AMO when no recommended results are found
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mossop, Assigned: mossop)
References
Details
At the moment if the first pull of recommended results returns nothing compatible we are lost and can't ever find any more since the results are cached.
This will add a random code to bypass the caching allowing us to pull more results and so increase the odds of finding compatible addons.
This would be good to hit b3 depending on how quick I can knock this out and get reviewed.
Flags: blocking-firefox3?
Comment 1•17 years ago
|
||
I don't think this is a good idea. I would prefer to cache the master list and randomize selection of a few on the client side.
The other option is to disable caching altogether, and I don't want to do this either. I am already nervous about making decisions like adding the random token when it creates a lower cache hit-rate for the sake of UI logic.
How hard is it to randomly select the recommended elements from the master list before handing them off to the add-ons manager? Also, why not just list all featured add-ons when the tab is loaded (or at least just load the ones needed to fill the pane).
Assignee | ||
Comment 2•17 years ago
|
||
Ok so the plan of adding a random token doesn't actually work to get around the caching anyway.
(In reply to comment #1)
> How hard is it to randomly select the recommended elements from the master list
> before handing them off to the add-ons manager? Also, why not just list all
> featured add-ons when the tab is loaded (or at least just load the ones needed
> to fill the pane).
The problem we have is that the current API returns a number of recommended results, the number being chosen by the client. The client then filters that result set removing add-ons that are incompatible or already installed. The problem is that right now retrieving even 25 results often yields just 1 that is compatible. Larger numbers of results seem to take longer to retrieve results increases fairly linearly up to about 4 seconds for 50 results.
I think the only thing to do here is to bump the number we pull by default and take the problem that we often will get no compatible results and know that it will alleviate as more add-ons become compatible.
Comment 3•17 years ago
|
||
Would it help to set up a staging instance so we can test this elsewhere? We can create faux add-ons that are compatible with fx3 until we have a strong enough sample set from the real add-ons universe. Any thoughts on that?
Comment 4•17 years ago
|
||
Second thought, we could always take a snapshot of production and make everything compatible with 3.*.
Assignee | ||
Comment 5•17 years ago
|
||
I don't see how that helps us. The point is for b3 users to see recommended addons that they can install.
Comment 6•17 years ago
|
||
Yep, you're right. Besides, it's too late for that now.
Assignee | ||
Comment 7•17 years ago
|
||
Ok by agreement with UX we will just leave this.
Flags: blocking-firefox3?
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Updated•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•