On Fri, 2011-07-29 at 15:24 -0400, Perry Myers wrote:
> * This console would have to either write its updates directly
to the db
> (which we have been trying to avoid, multiple writers, everything should
> go through conductor api), or call the conductor api, in which case we
> are doing almost everything the previous suggestion would do.
This point has always confused me... Multiple writers to a db is a
perfectly normal/logical thing as long as each writer has it's own
segmented space to write. If it's that big of a concern, then why not
create a separate database on the same DB server (if you're not
comfortable with table segmentation)?
The issue isn't so much the multiple writers to the DB (since as you
point out that's the bread-and-butter of RDBMS) but the processing that
needs to happen before you hit the DB, since you want to avoid
implementing the same business logic in two places.
With ovirt, we tried to tease apart the protocol-specific processing
(HTTP vs. QMF) and strict business logic with the 'service layer', it
was workable but awkward.
There is definitely room for a generic QMF/HTTP bridge: something that
takes in QMF events on a console (stats/property changes) and turns them
into HTTP requests. The other way (making QMF calls from a webserver)
fits much better with the general flow of a webapp, and would come down
to similar issues as DB connection handling causes, i.e. nothing too
dramatic.
David