Michal, > I would like to propose changes which will add new functionallity to the > IPS. Basically the changes will add new file/files on the server side, > which will contain specific meta data about fmri's. Other distributions > already have those kind of metadata[1]
We have a bug filed for this already. It's 243, please add the section in your proposal about the desired metadata to that RFE. > Benefits: > - Package Manager/Update Manager startup with fully loaded > descriptions will be reduced. Our goal is to have fully > functional GUI application with loaded data in less then 10 > seconds. This needs to be done in the scalable way, so the user > will not loose the performance even with loads of authorities. Every time the GUI team talks about loading all the data on startup, we inevitably have an argument about how and why this won't scale. This won't scale. This goal is unrealistic. Adding catalog metadata is fine, but it's not going to solve this problem. You need a different approach. We've discussed this multiple times. I'm tired of having our guidance on this issue ignored. > def refresh(self, full_refresh, auths=None, locales=["C",]): > """Refreshes the catalogs. full_refresh controls > whether to do a full retrieval of the catalog and > cataloginfo from the authority or only update the > existing catalog cataloginfo files. auths is a list of > authorities to refresh. Passing an empty list or using > the default value means all known authorities will be > refreshed. locales is a list of the locale specific > cataloginfo files which will be downloaded during > refresh operation. Passing an empty list will skip > getting locale specific cataloginfo files. The default > is an "C" cataloginfo file, which is supposed to be > downloaded. While it currently returns an image object, > this is an expedient for allowing existing code to work > while the rest of the API is put into place.""" The consumers of the API shouldn't be making a decision about whether a "full refresh" is necessary. The catalog already has a set of mechanisms that allow it to only download updated data, instead of an entirely new catalog. This mechanism, called the updatelog, should be extended so that it's possible to get updates to the metadata that has already been downloaded. > Because we can have multiply FMRI's for each package, the > cataloginfo file should store only those values which are > changing. This isn't correct. The catalog contains one entry for each package. The package is uniquely named by name and version strings. It would make sense to keep this information organized in a similar fashion. The ancillary catalog metadata for a package should be uniquely identifiable by package name and version. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
