* Jiri Srain <[email protected]> [Aug 14. 2009 10:06]: > Dne pátek 14 Srpen 2009 09:55:26 Michal Zugec napsal(a): > > Klaus Kaempf wrote / napísal(a): > > > * Michal Zugec <[email protected]> [Aug 13. 2009 16:07]: > > > >>>> But a config can get another attribute, "device" that makes it the > > >>>> default config for a device, and it works like our ifcfg (where > > >>>> "device" is in the filename) > > >>> > > >>> Don't over-engineer it ! Nothing in the feature request asks for the > > >>> separation of device and its config. > > >> > > >> For the future, this can be usefull. For wireless devices you can switch > > >> between several APs just by associate different configurations to one > > >> device. > > > > > > No question about the usefulness. Just focus on the simple parts (one > > > config per interface) now and extend later. > > > > Hm, but here's conflict of requirements. As I understand from Jiri, we > > should define rest-api not only for this simple purpose but also for > > future. We need to discuss this ... > > Perhaps I should re-word myself: My intention is to design the API so that we > do not have to rewrite it when we need e.g. support for multiple interfaces > (and therefore break other web clients or, even worse, existing vendor's > modules, which depend on that API).
We have to version the (rest-)api in any case. > > What I find important is extensibility of the interface without breaking > existing apps (e.g. adding more tags into a XML document is fine, so is > defining more paths). Such kind of extension is backwards-compatible. But clients requesting th extension still need a way to express this: versioning. See e.g. http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ for a discussion on versioning of rest services. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
