M. Ranganathan wrote: > On Thu, Feb 5, 2009 at 12:48 PM, Scott Lawrence > <[email protected]> wrote: >> On Thu, 2009-02-05 at 11:45 -0500, M. Ranganathan wrote: >> >>> I feel we (i.e. server writers) need better control over what gets >>> displayed. The reason is that we are calling libraries that we dont >>> necessarily have control over (In terms of what gets written to >>> stderr). These libraries may chose to write to stderr for any reason >>> at all. Later if you have a critical failure in your checking, what >>> gets displayed is what the library has written to stderr as the first >>> line -- not the actual error message of the exception that could >>> appear much later in the log file. >>> >>> It would be good if sipx-supervisor had the capability to filter >>> stderr ( using a keyword or specific xml tags to indicate the critical >>> error that YOU as server writer want to display to the user for >>> example ) rather than rely upon whatever appears in stderr. >>> >>> Any possibility we can add such a feature ? >> If there is any filtering to be done (and I am not sure there should >> be), it certainly should not be done in the supervisor. The sipXconfig >> is the user interface - do it there. >> >> Too much information is better than too little - don't filter. >> >> > > As a general principle not filtering that is a good rule. Here we have > a bit of a problem i.e. the first line that in the stderr output > (which is displayed in the sipxconfig console) may not be the actual > error cause. I think it would be a good idea to simply ask the user to > click for more information and not display the first line. >
I see: so you do not actually mean "the first" line. You just saying that no "single line" has enough information to be useful. Do I understand it correctly? I have no problem with such change, but I'd like to know what Joe and Carolyn think about removing one line preview. They probably spend more time on this feature that anybody else. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
