The key difference is that instead of trying to do everything for everyone at one time we're starting with as little as possible and building on it based on demonstrated demand and sensibleness of request. Richard has said that 50% of his instances use pre-assigned DHCP leases - the idea makes a lot of sense and costs us nothing to facilitate. If he asked us later we'd only need add it to a registry.
Use AtomPub and people who want CIM can still have it by
embedding and/or linking to it.
These are all important questions when turning theory into reality and we have two options:
- Don't care. Make a tight, inextensible API and let the clients pay for the limitations with extra code and workarounds, probably in the form of having to implement multiple APIs (e.g. OCCI + task specific).
- Play nice. Be extensible by allowing foreign markup for specification of advanced features we don't care about. For example, in a request to create/update a network resource one could embed a descriptor standardised by SNIA.
This doesn't hurt interop (at least not for the things we actually care about) because that information is still captured in the wrapper.
I hope it's becoming clearer why AtomPub (and I say AtomPub so as not to confuse it with POX) is the best choice for this problem by a country mile.
Sam