>> Its the size we want :( Tends to be more relevant for updates for users. > So how were you getting size quickly in the past? Slowly :) as part of the description. The UM GUI just makes it more obvious, the user tends to want to know how big an upgrade is before hitting install. >> [snip] >>>> One other problem I have at the minute is fetching info objects >>>> from the api is painfully slow. So for instance I'd like to display >>>> the size of the packages to upgrade in the treeview, but it takes >>>> over a second to fetch each info object to get this data from the >>>> manifest, which is way to slow for us. At the minute I just hide >>>> the size column and force the user to click on the row to get the >>>> details, including size . Not ideal but workable atm. What we >>>> really need is caching support on the client for the info objects >>>> and the underlying manifest data. Other wise we will end up doing >>>> the caching and that seems to be broken. >>>> >>> I would tend to say that caching information should be handled by >>> the client according to their needs, since different clients might >>> have vastly different cacheing protocols and needs, and to force a >>> single one into the API, or make several available via the API seems >>> the wrong direction to go to me. I'll admit I'm confused as to >>> exactly what the problem is. I understand that info is slow since it >>> must touch the disk to read the manifest, but how was that not the >>> case before? Doesn't packagemanager currently have to read in each >>> manifest from disk to get its summary and license anyway? I don't >>> think the API should replace whatever cacheing system you were using >>> to make that fast, I think it should replace those times when the >>> package manager was directly reading the manifest from disk. >> Well what would be nice would be to have pkg refresh take an optional >> cache option so it would save off a single cache file of all the >> manifest data that is in lots of separate files. Then when we have an >> API to retrieve the inventory and with the existing one to get info >> objects they could take a boolean option to retrieve it from the >> cache or directly. That way you hide the details from the clients but >> make fetching the manifest data a lot faster. Its up to the clients >> to make sure refresh has been called with the cache option. >> >> If this isn't done we will end up generating a cache file using >> UMNotifier to do the work and have the client consume it if its >> available, but then we will have different code paths for consumig >> the cache or the API info objects :( >> > > I feel reasonably certain this isn't code that should live within the > API, but I could be convinced otherwise. I do think that adding this > kind of cacheing into the API, would be a task that lived down the > road. Also, if you wanted to, you could write the caching stuff inside > the API, and use it as you wanted to, if you think it really belongs > inside there. Personally, I think it's potentially dangerous to say > things like "the client will always call refresh appropriately before > looking at the cached data" without a programmatic way of enforcing > such a constraint. > Sure but if you pass in a USE_CACHE boolean to the retrieval functions in the API and refresh hasn't been run with the cache option then just throw an exception to keep them honest, or else fall back to working without the cache. > Brock
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
