* Shawn Walker <[EMAIL PROTECTED]> [2008-06-09 15:33]: > 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. You can already uninstall without network connectivity. (The image metadata has all the information needed for an uninstall.) > 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.
Interesting, but I suspect that, since the client and the server have separate state machines expressing their relationship to a particular package, this reuse may not be as direct as the paragraph above hopes. - Stephen -- [EMAIL PROTECTED] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
