IWHD API Suggestions

Ian McLeod imcleod at redhat.com
Mon Sep 12 15:13:45 UTC 2011


On Mon, 2011-09-12 at 16:04 +0200, Jim Meyering wrote:
> Matt Wagner wrote:
> 
> > On Fri, Sep 09, 2011 at 07:59:49PM +0200, Jim Meyering wrote:
> >> Not without compromising a fundamental design attribute:
> >>
> >>   iwhd is an object store
> >>
> >> It does not know which objects correspond to images, builds, target
> >> images, etc.  All it has is semantic-free "objects", each in some
> >> bucket, and possibly with its own set of attributes.
> >
> > Okay, I think I now understand the point you made and I wasn't getting
> > earlier -- iwhd is meant for storing the images, and we should be using
> > something else for storing extended metadata about them.
> >
> > For now we can limp along with status quo, but we should find a good
> > place to store this information because what we're doing now is less
> > than ideal. I'd really love to find a way to do this without adding yet
> > another daemon, though.
> 
> If only one client interface is actually updating objects in iwhd
> that you care about, the intermediate layer can be a class in that
> client.  The only reason to make it a separate process is if
> updates may go through multiple clients, presuming we can't
> depend on all of them to follow the same rules.

We will always have at least two clients, the Factory and the Conductor,
with the Factory primarily creating and updating objects and the
Conductor primarily reading them.  

I will re-state the obvious and point out that the primary issue with
Conductor-side caching is that we have no structured way of informing
the Conductor when a new object is created by the Factory in the
Warehouse.

-Ian



More information about the iwhd-devel mailing list