On Tuesday 18 August 2009 10:37:44 Klaus Kaempf wrote:

Hi,

the requirements for WebYaST contain a couple of vendor-configurable parts. Some are on the frontend (branding), some on the backend (setup workflow, services, ...).

The current approach is to implement vendor configurations spread among many backend modules.

I wonder if this is the right approach and if it wouldn't be better to have a single, shared implementation (class ? service ?) to cover this all.

A single implementation would ensure consistency in file formats and locations as well as a single documentation.

This is mostly for Josef and Jiri to agree upon ;-)

I was talking with Björn about this earlier, because the status has to show a custom package list that needs to be stored in a configuration file. So the installed packages resources should be able to filter by this custom setting. I propose this: http://www.gliffy.com/pubdoc/1795703/L.jpg Use cases: imagine appliance CoolDb with a shiny moon logo, they have a custom bug reporting site - The service is running in the same appliance machine. The webclient may be not. - If you call /installed_packages?filter=custom, the service is running in the same appliance, so it can use the API to get the custom packages to display. The API will provide access to this collection of customization files. - If the client is in another machine, there will be other settings that the client will need to retrieve _from_ the appliance in order to make some sense in the user interface, example: * If the client is in another machine, and a module crashes, you want still to show the link to the bug page of the vendor, which is configuration in the server side, therefore we need to expose those settings in a core settings controller/resource. - If the client is local to the appliance you get the branding. If the client is remote, I think it is a reasonable to leave the branding out What do you think? -- 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

On 08/18/2009 10:37 AM, Klaus Kaempf wrote:

Hi,

the requirements for WebYaST contain a couple of vendor-configurable parts. Some are on the frontend (branding), some on the backend (setup workflow, services, ...).

The current approach is to implement vendor configurations spread among many backend modules.

I wonder if this is the right approach and if it wouldn't be better to have a single, shared implementation (class ? service ?) to cover this all.

A single implementation would ensure consistency in file formats and locations as well as a single documentation.

This is mostly for Josef and Jiri to agree upon ;-)

Klaus

Yes, I agree. We should have allocated place (like somewhere in /etc/YaST2) I only need read permissions to this file. Also if we abstract above loader we should in future improve it or change it and it affects all code. So I agree.

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

-- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, webyast modules language and time -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org