Right now in we have a web-service called services with it corresponding web- clent part. On Friday morning this was implemented using the YaPI and on Friday afternoon it was reverted to the old codebase using some lsbservice.rb code. Now there is a new custom_services plugin, AFAIK this is because the services feature has to do with a custom vendor service and not with all system services, and now nobody knows what will happen to the old services plugin. I am really confused about the requirements and the design in general (and I am worried about the direction it is taking), here are my points: - Are we going to make application vendors have to use a different APIs for services and for "custom services"? that goes against any UNIX design. - If we want to provide customization or support for non-LSB services, why do we need a separate API than lsb services instead of making the services API work with both? - Are we going to make a plugin just to provide a service API based on a vendor custom start/stop/status script? Can anyone please compare the effort of customizing that with actually either forcing the vendor to provide a LSB init script or to actually provide a lsb wrapper script that can be sourced after defining 4 variables, and for which we get the quite nice feature of managing all services through the same interface? I think the design is escaping simplicity, I would propose this approach: - Having _one_ and only one services plugin in the service side. The implementation of this REST API would access the init.d scripts, and additionally would do the following things: - also read another directory with yml files where and recognize custom services there. The vendor provides the variables in those yml, and the services plugin knows how to handle those. However the LSB services are - Having ONE, and only ONE web client module for the services The implementation of the Web client would also recognize a yml file in certain directory that would allow to hide certain services and allow branding of others. That way, the vendor can customize what to show. If the problem of which services are visible is determined on the client side (so if you access a remote host from the client you see all services) then this configuration can then be in the service side, and the API will hint the client which services need to be hidden, or whatever. This should be a hint, respected by our client, but we should allow 3rd party consumers Benefits of this approach: - we get a services API that works for all services - vendors have the choice to use LSB services or a easy way via a config file - the cient can show the data in the way the vendor wants by respecting the hints of the API, however a 3rd party API consumer can see all services as equal. Comments? -- 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org