Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] WebYaST: Network REST Model v1
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Fri, 14 Aug 2009 10:20:53 +0200
  • Message-id: <20090814082053.GA670@xxxxxxxxxxxxx>
* Jiri Srain <jsrain@xxxxxxx> [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 <mzugec@xxxxxxx> [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

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.
for a discussion on versioning of rest services.

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >