On Mon, Jun 9, 2008 at 7:50 PM, Dave Miner <[EMAIL PROTECTED]> wrote: > 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.
Dpkg has this feature and I have seen at least one person actually using it on his laptop several times (Debian Potato). An out-of-sync check is always performed before doing a batch operation. The other thing being inability to view package info while disconnected. Regards, Moinak. > > Dave > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
