2008/6/9 Michal Pryc <[EMAIL PROTECTED]>: > Shawn Walker wrote: >> >> 2008/6/9 Michal Pryc <[EMAIL PROTECTED]>: >>> >>> Shawn Walker wrote: >>>> >>>> 2008/6/9 Dave Miner <[EMAIL PROTECTED]>: >>>>> >>>>> Moinak Ghosh wrote: >>>>>> >>>>>> 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. >>>> >>>> I have to agree with Dave. >>>> >>>> I'm not aware of any systems that have such functionality, and I don't >>>> think it is a usage case worth supporting. >>> >>> The GUI for IPS (packagemanager) needs such usage. >> >> I was speaking about the offline functionality. Not about the current >> usage pattern of making selections of items to install and then >> installing them. > > I was thinking about local cache to speed up loading descriptions, as an > extra addition it will give off-line functionality.
Obviously the ability to uninstall items without a network connection is a necessary bit of functionality so some form of caching has to be implemented. I just wasn't keen on the particular usage case previously mentioned. As for caching... One of the changes I want to make is to move all of the depot specific code currently in modules/server/repository.py to modules/server/depot.py. The repository code would then just deal in file operations and the depot code would simply be a protocol specific wrapper (https, etc.) around the repository. This would allow the client to perform installs from the filesystem (directly), http://, https://, etc. Going further, this means that it would be relatively easy for a client to use these new objects to build its own repository using the manifest files, etc. that it retrieves. This would also mean that we could make the client's operations for search, info, contents, etc. rely on the repository code for them instead of having to have a duplicate set of code to perform those same operations on the client in a different way. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
