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. Ciao, Daniel -- J. Daniel Schmidt <[email protected]> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
