Bart Smaalders wrote: > Michal Pryc wrote: > >> Hi, >> I have already asked about this few months back: >> http://mail.opensolaris.org/pipermail/pkg-discuss/2008-March/002217.html >> >> There is an script which shows how the description are taken from the >> manifest file. To get GUI up and running we need to have descriptions >> for *all* packages, so currently this is quite long task, more then that >> this is even longer if the manifests are not in the local catalog. >> >> The acceptable time for such option would be less then 1 seconds which >> is far from what is now. Currently each time user starts GUI the number >> of opened manifest files is the number of all packages, just to get >> description, that is why I think (I might be wrong) that caching this >> kind of information will give huge performance improvement. >> >> If you have any other suggestions I would be very happy to go other then >> caching way. >> >> The bug 243 should cover this as Danek wrote in that thread: >> http://defect.opensolaris.org/bz/show_bug.cgi?id=243 >> >> I am attaching dtrace script which shows opened and written files (O/W) >> running this script together with the script attached in the e-mail >> from March would give information how much files needs to be opened and >> how slow is getting description information. >> >> ./print_changes.d /path/to/the/ips/catalog >> > > > Rather than caching, etc, I'd like to suggest that using the search > mechanism to retrieve information is a better approach. > > This would allow for the quick retrieval of descriptions, icons, etc, > from current or new repos. > > - Bart > > I'm not sure how you're envisioning using the search mechanism to do this. To my knowledge, search doesn't currently support getting the description (for example) of a specific package. This wasn't a use case for search which I had thought of so I'll have to consider whether the new version of search would have the capacity to do this (at least if it provides (or could provide) the data structures to make this efficient)
Also, setting aside whether or not search could do this, isn't the cost of transferring all of this information from a remote server on start up each time prohibitive? Especially for things like icons, isn't that a large amount of data to pull across the network given the time frame (< 1 sec) we're considering? If I understand correctly, there are really two problems: pulling information for all the local individual manifest files takes too long; pulling the information for manifests not stored locally takes way too long. On the first, I suppose there's no reason (other than duplication of data) not to gather this information and pkg install time and add it to a central location. On the second, given that hitting the server seems unavoidable to me (which means the 1sec constraint is likely to be violated), perhaps what should be done is the program caches a small subset of what it will need to retrieve from the server (which would probably be gui dependent since different gui's might prioritize different packages) then it can show the user the cached information while it goes off and asks the server for updated information on those packages and fills in the rest of its package descriptions. Brock _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
