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: [email protected] For additional commands, e-mail: [email protected]
