[EMAIL PROTECTED] wrote: >> As John points out, different consumers of the API may desire different >> tradeoffs. Yes, if we could be blindingly fast and use no memory, that >> would be ideal. I saw the "use_cache" flag as the beginning of a low >> memory mode. Or, we might discover that the right way to think about >> these things is a persistent/long-running vs one-off/short-running flag. >> If we can't be perfect for everyone, I'd rather give API consumers >> switches to flick rather than say "oh well, too bad for you." If you >> agree on that, then, essentially, I think what we're quibbling about is >> whether "use_cache" should be named something else. >> > > I don't agree on this. We should be able to perform well without > requiring lots of switches to flip, depending upon a bunch of arbitrary > conditions. We need to deal with optimizing the memory footprint; > however, Bart observed that we're not done adding features that require > keeping manifest data in memory. Once those features have been > integrated, we'll be in a better position to assess a design. Trying to > fix this now is a premature optimization. > > I wasn't saying we should fix this now in the general case. >> In short, I think "use_cache" starts to lay the track for later work we >> may need to do anyway. >> > > We have no way of knowing until we evaluate the later work. > We won't know, that's true. We can make educated guesses about future state. Had we decided to put the flag in and it turned out not to be needed, it could always be removed. > >> The other change, 'if name == "pkg" ', is clearly only a stopgap >> measure. It doesn't provide other (hypothetical) consumers of the API >> the ability to choose whether they use the cache or not (run in low >> mem mode or not) (declare they're long running processes or not). >> > > That's the entire purpose of this change: a stopgap measure. I don't > believe we should be providing API consumers with the choice about using > cache or not. There's no reason that the consumers need to know that a > cache is present. > > All I was saying is that I think the use_cache approach might have laid some ground work for future work as opposed to only being a stopgap and if it turned out not to be needed, then relegating it to stopgap status does no harm.
As for the cache. I agree, ideally the consumers shouldn't need to know that a cache exists. If that's the case though, then we need to invest time and energy (eventually not saying right this moment) into good cache management which handles both short and long running processes, low and high memory conditions, as well as covering the different use patterns between install, image-update, info, list, possibly search in the future, etc... I believe we can develop that structure, but it's not trivial work. Until we have that in place, I'd argue that providing a switch is better than forcing everyone into the exact same box. Now, all of that strays pretty far from the actual important decision for 2008.11. For this release, I'm fine with going with the solution Shawn proposed, especially if we agree that cache management needs to be on the plate for 2009.04. So let's go with the "name==pkg" approach for now in the interest of getting 2008.11 out the door. Brock > -j > > _______________________________________________ > 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
