Mailinglist Archive: yast-devel (246 mails)

< Previous Next >
Re: [yast-devel] Vendor configuration service ?!
  • From: "Duncan Mac-Vicar Prett" <dmacvicar@xxxxxxx>
  • Date: Tue, 18 Aug 2009 12:51:30 +0200
  • Message-id: <200908181251.30255.dmacvicar@xxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References