Mailinglist Archive: yast-devel (59 mails)

< Previous Next >
Re: [yast-devel] Showing state of WebYaST plugins in status plugin.
  • From: "J. Daniel Schmidt" <jdsn@xxxxxxx>
  • Date: Mon, 22 Mar 2010 14:52:23 +0100
  • Message-id: <201003221452.23920.jdsn@xxxxxxx>
On Monday 22 March 2010 13:26:12 Josef Reidinger wrote:

Implementation of notification is up to you (you can use db which we
have on ws or files etc..). and then solution comes in different way
how to handle when you know that problem exist.

This moves module specific know how into the status module. It needs to be
maintained twice then.

1) simple know what each problem is and handle it
in status module, easy to implement solution not so easy to extend,
especially by external vendors

This isn't even easy to implement, as the status module needs to know how to
query for exactly what in a foreign module - and if these modules change, the
status module needs to be adapted too. This will sooner or later get
inconsistent and messy.

2) each ui controller which can have
problems in ws has methods problems which return array of rendered
contents for status notification. So it can include also link to fix it
and other usability improvements -

Why should this go into the ui controllers? Its the backend that knows about
the status of the module or its configuration.

to be universal, you need to store name
of controller, so you know which controller you must ask. (or you can
simple ask all ui controller and don't need any notifications)

This "get the correct status" approach should become so generic that we should
not need to touch it anymore just to hook in any other module. Just think of
custom modules from software vendors. If they need to change our code to hook
in their modules it could damage even more.
But if we provide a generic framework everybody could easily include his
custom module to the status information.

The question now is, what is the best way to do it?

I like the idea that every module that responds to the method "status" could
will be integrated into the status info (see "status" as a symbol, we can of
course change that name). Thats a pretty simple way to offer thirt parties a
way to include their module status and a clean an generic way for ourselves.
And it even follows the basic concept of REST.


J. Daniel Schmidt <jdsn@xxxxxxx> SUSE Linux Products GmbH
Research & Development Maxfeldstr. 5
GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >