> 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. > 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. > 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. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
