IWHD API Suggestions

Matt Wagner matt.wagner at redhat.com
Fri Sep 9 17:17:39 UTC 2011


On Fri, Sep 09, 2011 at 06:56:34PM +0200, Jim Meyering wrote:
> Hi Matt,
> 
> Maybe you already do this?
> 
> At least with the current architecture, I would suggest that you read as
> much as you need initially to construct the graph of relationships.  While
> doing that, you can add back-links, as needed, so that when you iterate
> through UUIDs, each query merely examines your in-memory representation
> and you get results in O(1) time per UUID.

I've discussed doing this as a work-around in the interim. But this
leaves us mirroring the entirety of images, builds, target images, and
provider images in our app. (Well, the metadata for each, not the actual
image files, of course.)

But this pretty quickly grows into 50+ API calls to populate the above.
Doing that once is tolerable, but the problem is that this information
can't really be cached, so we need to do this for every request, which
basically negates the benefit of trying to read it all on our end in the
first place. Is there any sort of optimization to this that you see?

> Then, if the read-all phase is still found to be too slow, say, due to the
> number of queries required, we can think about adding an API to provide
> larger batches of information, rather than imposing application-specific
> structure on iwhd.

I don't understand how this is application-specific. A build can show me
what image it is for. There's no way to provide that functionality in
reverse and have an image show me what builds it has? It seems like this
could be broadly useful.

Best,
Matt


More information about the iwhd-devel mailing list