Moinak Ghosh wrote: > 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. >
Are there any extant systems where users actually do this? It seems a little too theoretical to me at first glance. It would also seem to raise a host of issues around the effects an out-of-sync manifest cache would have on such a stored batch operation. All in all, I'm skeptical I'd want it. Dave _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
