Bug 12897 - Reduce number of network calls for home menu item icons
: Reduce number of network calls for home menu item icons
Status: NEW
Product: SqueezePlay
Classification: Unclassified
Component: Networking
: unspecified
: PC Other
: -- normal (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-16 12:07 UTC by Wadzinski Tom
Modified: 2011-11-06 23:24 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wadzinski Tom 2009-07-16 12:07:17 UTC
Dump of campfire discussion:
Andy G.	
Tom: fetching all icons in the menu even if most aren't shown, do you think that should be fixed?
11:55 AM
Andy G.	
it does make for a smoother transition into radio for example, since all the icons are already cached
but it's a lot of requests, etc
Tom W.	
Hmmm, I don't have a strong opinion.. how many are we talking about?
I would think going to a rhapsody collection for instance would be quite a bit more
Andy G.	
but doesn't it only fetch what's visible?
+ a few more or something like that?
Tom W.	
I don't know that code... Perhaps Richard or Ben could weigh in, and/or I could create a bug to re-evaluate the consequences of fetching all the home menu icons
Andy G.	
I think it's something like 24 icons it fetches now
Felix M.	
Richard: I am about to update the wlan driver to 2.1.2.62. That should go into baby-mp branch, yes?
Ben K.	
sorry, all icons in which menu?
Andy G.	
everything from the menu response
so basically all services
Ben K.	
if you only fetch what's visible it's going to be laggy
Andy G.	
yeah I know, I wonder if we can deliver the 24 icons more efficiently or something
12:00 PM
Andy G.	
they are very small (resized by the server)
Tom W.	
all home menus. Worst cases is the typical one, when the user is connected to SC, they'll get 24 from SC and 24 from SN because I believe that a per server cache is used
Ben K.	
on-the-fly zip/unzip? i think we tried that during jive development...
Andy G.	
or just all in 1 request
Ben K.	
oh, sure
Tom W.	
still probably not something for the near future, so a bug?
12:05 PM
Andy G.	
fair enough
Comment 1 Ben Klaas 2009-08-26 07:53:16 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 2 Chris Owens 2010-03-15 18:05:08 UTC
7.4.x milestone is in the past
Comment 3 Chris Owens 2010-05-06 15:37:59 UTC
Tom is no longer available to us
Comment 4 Alan Young 2011-11-06 23:24:29 UTC
Unassigned bugs cannot have a priority.