[Ovirt-devel] Ovirt QMF API Proposal

[Daniel P. Berrange]

On Wed, Apr 01, 2009 at 04:29:06PM -0700, David Lutterkort wrote:
> On Wed, 2009-04-01 at 16:44 -0400, Jeremy Katz wrote:
> > On Tuesday, March 31 2009, Ian Main said:
> > > Through much discussion it was decided that we would leverage the rails
> > > models created for use in the WUI, and create an alternative way to
> > > access these models, start tasks etc.  This will be integrated with the
> > > current task management system (taskomatic) to produce a complete package.
> > > 
> > > The idea is to create a set of classes available via QMF as objects.
> > > These classes would then be backed by either a mid-level API that
> > > encompasses the models, or by active record models directly.  Any changes
> > > made to these records outside of the API (eg by the WUI) would require
> > > notification of changes to taskomatic.
> > 
> > So, by integrating deeply like this, how much is going to be tied to underlying 
> > implementation details that (may|might|will) change in the future?  From
> > looking through it, it seems very tightly tied which given the many
> > unanswered questions, is at least of some concern imho.
> 
> Can you give examples of what in the API proposal worries you in that
> regard ? What the QMF API exposes isn't too different from what the REST
> API (would) expose.

I was just going to ask about the REST api....

The idea of having a formal QMF API is very nice, but I can't help thinking
it will limit the potential userbase of the API since you of course need to
get a QMF api for your client. The really compelling thing about REST APIs
is that they are immediately usable by any client which has web browsing
capabilities - which is basically every device with a network connection
these days. No extra/special client side software required.

I could see a REST and QMF api co-existing - perhaps you could in fact
write one in terms of the other to provide guarenteed parity of functionality
between the two, and reduce the burden of having 2 apis.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|