On Mon, May 11, 2009 at 10:00:09PM +0100, John Rice wrote: > Shawn Walker wrote: >> jmr wrote: >>> Padraig - as this is post 2009.06, I'd like us to review all the Tab >>> panels and decide what they should look like. As we are introducing a >>> Tree View to get around l10n layout issues, I think we could use the >>> installed icon in the Dependencies tab if we also change it to use >>> the Tree View. We should review all this with Jenya. >>> >>> Whatever we do its good to know the performance is not an issue here >>> for fetch and display this info. >> >> There should no longer be a performance issue in calling api_o.info() >> to obtain package information. In fact, if done properly, there >> should no longer be a need for the GUI to cache this information as >> manifest accesses are very cheap now. > So Shawn is it now very cheap for me to access manifest data such as > description of packages that are not installed on the system, but in the > repository? If this is the case then great, I would be delighted to > remove the cache, if not then we still have a problem. >> >> There are three key changes I'd like to see in the GUI post 2009.06: >> >> * Elimination of cache >> >> * Change to --not-- load information of all packages in memory > Same issue as above, how do you propose that we get information on > packages that are in the repo but not installed on the system in a > timely manner? >> >> * Move to using api.info() always instead of using manifest > If it does what we need no issue there.
I'm surprised that we're still having this argument. The number of packages in a publisher is unbounded, as is the number of publishers that a client may configure. Given that our dataset is potentially enormous, it's not scalable or practical to download and cache the data for all packages the client might forseeably install. Given the challenges involved with caching an unbounded amount of data in a client machine that has finite resources available, it would make more sense to retrieve package details on demand, or use a search-based approach that only retrieves details for packages that a client might be looking for. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
