Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] Re: about the services module direction
  • From: "Duncan Mac-Vicar Prett" <dmacvicar@xxxxxxx>
  • Date: Tue, 18 Aug 2009 10:06:58 +0200
  • Message-id: <200908181006.58790.dmacvicar@xxxxxxx>
On Tuesday 18 August 2009 09:10:48 Jiří Suchomel wrote:
Sure, that's what I mean by that second UI. We should probably have 2 web
clients, one "services" for /etc/init.d services and one
("custom_services"?) for vendor specific service. Both would use the same
"services" REST API, with "index", "show" and "update" paths.

I can't say if it will be more usable having two modules, and why two are
needed, because I don't understand what reason creates the need for two. We
could have only one, and support showing the custom services only because it
is the only priority. But what one implements at the beginning is tied to the
priorities, but the design is more looking the forest than choping trees.

A typical design pattern here is to use URL parameters, so the API could
return all services when GET. But if ?filter=custom is passed, then the
custom_services.yml is read and only those are returned.

I was discussing the same design pattern with Björn for the service to return
a ISV defined list of software versions. In this case one can make a installed
packages resource that returns all packages, and add a ?filter=favorites that
would read the config file with the appliance important packages list. Then
adding other filters is piececake, to satisfy different requirements. The
weird solution would have been creating a resource /custom_packages.

Duncan Mac-Vicar P. - Engineering Manager, YaST
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

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

< Previous Next >