Re: [Nagios-devel] Fix CSV output in avail.c
Posted: Mon Jan 09, 2012 5:38 pm
> Fr=E5n: Andreas Ericsson =0A=0A> Till: Sven-G=F6ran Bergh ; Nagios Developers List =0A> Kopia: =0A> Skickat: m=E5ndag, 9 januari 2012 16:38=0A=
> =C4mne: Re: [Nagios-devel] Fix CSV output in avail.c=0A> =0A> On 11/28/20=
11 09:04 PM, Sven-G=F6ran Bergh wrote:=0A>> Hi,=0A>> =0A>> attached patch=
fix the CSV output from avail.c=0A>> to comply better with RFC-4180, see=
=0A>> =0A>> http://www.ietf.org/rfc/rfc4180.txt.=0A>> =0A>> Content-type =
now is Text/csv, so the browser=0A>> presents a view/save dialog.=0A> =0A>=
How is this an improvement over just hitting Ctrl+S once the page=0A> has =
loaded? Personally, I detest when pages I *know* is plain text=0A> forces m=
e to click something just in order to either view or save,=0A> when saving =
after it's viewed is so simple anyway.=0A=0ATwo of the reasons to why the p=
atch was written in the first place=0Aare:=0A- The Nagios CGIs are embedded=
in another GUI app that AJAX-load=0A=A0 the CGI pages in a div element. To=
get a stand alone window that=0A=A0 is possible to Ctrl+S save would mean =
a lot of tweaking, while the=0A=A0 result would violate an otherwise smooth=
GUI.=0A=0A- Our users are no techies. An additional step would require a m=
anual=0A=A0 (yah, no kidding) that no one reads anyway. They just want to g=
et=0A=A0 the data directly into a spreadsheet with as little hassle as=0A=
=A0 possible.=0A=0A>> Likewise, CRLF is used.=0A>> =0A> =0A> This could be=
tricky. I know there are parsers out there that handle=0A> the Nagios-styl=
e CSV format, and if they break because we suddenly=0A> choose to go strict=
with the style we use, we shove a broomstick up=0A> our asses for no gain =
what so ever.=0A> =0A> So... Have you verified that this patch doesn't brea=
k anything, or=0A> is that supposed to be an exercise for one of the mainta=
iners? If=0A> you haven't done it, it's unlikely to get done at all, and in=
that=0A> case the CRLF part of the patch will almost certainly have to be=
=0A> dropped or modified so that line-endings are given as a character=0A> =
sequence by the user instead.=0A=0ANo, I have not run any additional tests.=
Just a normal compilation=0Aand our own in-house parser. Any specific pars=
er/test you are thinking=0Aabout? Hmm, I will try to look into a solution w=
ith desired line-=0Aending supplied as a URI query variable that defaults t=
o LF-only.=0AFeel free to drop the CRLF part for the moment. I'll be back.=
=0A=0ABrgds=0A/S-G=0A
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> =C4mne: Re: [Nagios-devel] Fix CSV output in avail.c=0A> =0A> On 11/28/20=
11 09:04 PM, Sven-G=F6ran Bergh wrote:=0A>> Hi,=0A>> =0A>> attached patch=
fix the CSV output from avail.c=0A>> to comply better with RFC-4180, see=
=0A>> =0A>> http://www.ietf.org/rfc/rfc4180.txt.=0A>> =0A>> Content-type =
now is Text/csv, so the browser=0A>> presents a view/save dialog.=0A> =0A>=
How is this an improvement over just hitting Ctrl+S once the page=0A> has =
loaded? Personally, I detest when pages I *know* is plain text=0A> forces m=
e to click something just in order to either view or save,=0A> when saving =
after it's viewed is so simple anyway.=0A=0ATwo of the reasons to why the p=
atch was written in the first place=0Aare:=0A- The Nagios CGIs are embedded=
in another GUI app that AJAX-load=0A=A0 the CGI pages in a div element. To=
get a stand alone window that=0A=A0 is possible to Ctrl+S save would mean =
a lot of tweaking, while the=0A=A0 result would violate an otherwise smooth=
GUI.=0A=0A- Our users are no techies. An additional step would require a m=
anual=0A=A0 (yah, no kidding) that no one reads anyway. They just want to g=
et=0A=A0 the data directly into a spreadsheet with as little hassle as=0A=
=A0 possible.=0A=0A>> Likewise, CRLF is used.=0A>> =0A> =0A> This could be=
tricky. I know there are parsers out there that handle=0A> the Nagios-styl=
e CSV format, and if they break because we suddenly=0A> choose to go strict=
with the style we use, we shove a broomstick up=0A> our asses for no gain =
what so ever.=0A> =0A> So... Have you verified that this patch doesn't brea=
k anything, or=0A> is that supposed to be an exercise for one of the mainta=
iners? If=0A> you haven't done it, it's unlikely to get done at all, and in=
that=0A> case the CRLF part of the patch will almost certainly have to be=
=0A> dropped or modified so that line-endings are given as a character=0A> =
sequence by the user instead.=0A=0ANo, I have not run any additional tests.=
Just a normal compilation=0Aand our own in-house parser. Any specific pars=
er/test you are thinking=0Aabout? Hmm, I will try to look into a solution w=
ith desired line-=0Aending supplied as a URI query variable that defaults t=
o LF-only.=0AFeel free to drop the CRLF part for the moment. I'll be back.=
=0A=0ABrgds=0A/S-G=0A
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]