On Sat, Jun 7, 2008 at 1:46 AM, Bart Smaalders <[EMAIL PROTECTED]> wrote: > Brock Pytlik wrote: >> 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. >>>> [...]>>>> >>>> ./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. >> > > > A small local cache is fine as a gui hack, but I'd much rather work towards > a model of retrieving descriptions and icon pointers dynamically. The icons > can be cached locally by hash.
It is fine to fetch information as and when the user clicks on the package name. However this constant dependence on network connection does not sit well with laptop mobility. User with laptops on the move will be unable to check package information half the time. One use case I can think of is that a user has to do a bunch of package operations and he meticulously makes package selections/deselections while on a plane/ train and stores this as batch operation to be processed later. Later when he reaches and gets onto a network he just fires off the batch operation and does other work. This or similar scenarios won't be possible if pkg metadata is not locally cached. Regards, Moinak. > > - Bart > > > -- > Bart Smaalders Solaris Kernel Performance > [EMAIL PROTECTED] http://blogs.sun.com/barts > "You will contribute more with mercurial than with thunderbird." > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
