I just had one of my checked-email-first-thing-out-of-bed-and-had-what-seemed-like-a-great-idea-at-the-time moments. Note that I am not currently up-to-date on everything folks have been doing with PackageKit on FL up to this point, only that there are still a lot of usability issues to work out.
If everyone who uses PackageKit is querying the same repository, and Conary repquery is the reason browsing available software is slow, my idea to work around that issue is to have something in the middle (from FL, not running on the client) that PackageKit is fetching instead of running a full repquery, and have that middle thing doing all the requery work in the background constantly running a new requery each time there's a commit to the repository. This middle item would simply me a static index of repository contents that is being constantly updated, but that is an easy-to-retrieve format like a CSV file. PackageKit <---> Index of Repository Query Results <---> Conary Repository If the user selects items in PackageKit after that, the new conary update commands can still be formed and executed against the repository at that time. Thoughts? Has anyone considered this approach before? Any confirmed sticking points? I'd like to try my hand at planning and coding something like this, but I would need time to get familiar with the PackageKit code, too, and have an understanding of the approaches people have been taking so far. -Stef -- Stephanie Watson Raleigh, North Carolina _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
