Re: [Nagios-devel] [patch] Fix CSV output in avail.c revisited
Posted: Fri Feb 03, 2012 3:19 pm
On 01/10/2012 02:31 PM, Sven-Göran Bergh wrote:
>> Från: Andreas Ericsson
>
>> Till: Sven-Göran Bergh
>> Kopia: Nagios Developers List
>> Skickat: tisdag, 10 januari 2012 10:07
>> Ämne: Re: [Nagios-devel] Fix CSV output in avail.c
>>
>> On 01/09/2012 06:38 PM, Sven-Göran Bergh wrote:
>>>> Från: Andreas Ericsson
>>>
>>>> Till: Sven-Göran Bergh; Nagios Developers List
>>>> Kopia:
>>>> Skickat: måndag, 9 januari 2012 16:38
>>>> Ämne: Re: [Nagios-devel] Fix CSV output in avail.c
>>>>
>>>> On 11/28/2011 09:04 PM, Sven-Göran Bergh wrote:
>>>>> Hi,
>>>>>
>>>>> attached patch fix the CSV output from avail.c
>>>>> to comply better with RFC-4180, see
>>>>>
>>>>> http://www.ietf.org/rfc/rfc4180.txt.
>>>>>
>>>>> Content-type now is Text/csv, so the browser
>>>>> presents a view/save dialog.
>>>>
>>>> How is this an improvement over just hitting Ctrl+S once the page
>>>> has loaded? Personally, I detest when pages I *know* is plain text
>>>> forces me to click something just in order to either view or save,
>>>> when saving after it's viewed is so simple anyway.
>>>
>>> Two of the reasons to why the patch was written in the first place
>>> are:
>>> - The Nagios CGIs are embedded in another GUI app that AJAX-load
>>> the CGI pages in a div element. To get a stand alone window that
>>> is possible to Ctrl+S save would mean a lot of tweaking, while the
>>> result would violate an otherwise smooth GUI.
>>>
>>> - Our users are no techies. An additional step would require a manual
>>> (yah, no kidding) that no one reads anyway. They just want to get
>>> the data directly into a spreadsheet with as little hassle as
>>> possible.
>>>
>>>>> Likewise, CRLF is used.
>>>>>
>>>>
>>>> This could be tricky. I know there are parsers out there that handle
>>>> the Nagios-style CSV format, and if they break because we suddenly
>>>> choose to go strict with the style we use, we shove a broomstick up
>>>> our asses for no gain what so ever.
>>>>
>>>> So... Have you verified that this patch doesn't break anything, or
>>>> is that supposed to be an exercise for one of the maintainers? If
>>>> you haven't done it, it's unlikely to get done at all, and in that
>>>> case the CRLF part of the patch will almost certainly have to be
>>>> dropped or modified so that line-endings are given as a character
>>>> sequence by the user instead.
>>>
>>> No, I have not run any additional tests. Just a normal compilation
>>> and our own in-house parser. Any specific parser/test you are thinking
>>> about? Hmm, I will try to look into a solution with desired line-
>>> ending supplied as a URI query variable that defaults to LF-only.
>>> Feel free to drop the CRLF part for the moment. I'll be back.
>>>
>>
>> I've done so. Since the only editor I know of that screws up LF/CRLF
>> differences in Windows is Notepad, I'm not overly fussed about this
>> and would rather just ignore it completely. I know all the major
>> office suites (Open, Libre and MS) handle LF line-endings just fine
>> in csv input though.
>
>
>
> I hear you. The patch is now revamped to listen to the user. By default
> nothing is changed.
>
> Summary:
> - CSV output is either as today, or strict compliant with RFC4180.
> No in betweens.
>
> - If the URI query parameter "csvstrict" is supplied together with
> csvoutput. The output will be strict according to RFC4180.
> - Otherwise, the output is the same as today.
>
> - An additional checkbox for csvstrict has been added
>
> - Output according to RFC4180 has the following changes compared to the
> traditional output: - HTTP, changed header: Content-Type: text/csv; header=present
> - HTTP, new header: Content-Disposition: attachment; filename=availability.csv
> - CSV, line-ending is CRLF
> - CSV, no spaces inside CSV fields
>
>
> Hope you like this better. The patch is against the 3.3.1 release.
>
This one duplicates all the
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
>> Från: Andreas Ericsson
>
>> Till: Sven-Göran Bergh
>> Kopia: Nagios Developers List
>> Skickat: tisdag, 10 januari 2012 10:07
>> Ämne: Re: [Nagios-devel] Fix CSV output in avail.c
>>
>> On 01/09/2012 06:38 PM, Sven-Göran Bergh wrote:
>>>> Från: Andreas Ericsson
>>>
>>>> Till: Sven-Göran Bergh; Nagios Developers List
>>>> Kopia:
>>>> Skickat: måndag, 9 januari 2012 16:38
>>>> Ämne: Re: [Nagios-devel] Fix CSV output in avail.c
>>>>
>>>> On 11/28/2011 09:04 PM, Sven-Göran Bergh wrote:
>>>>> Hi,
>>>>>
>>>>> attached patch fix the CSV output from avail.c
>>>>> to comply better with RFC-4180, see
>>>>>
>>>>> http://www.ietf.org/rfc/rfc4180.txt.
>>>>>
>>>>> Content-type now is Text/csv, so the browser
>>>>> presents a view/save dialog.
>>>>
>>>> How is this an improvement over just hitting Ctrl+S once the page
>>>> has loaded? Personally, I detest when pages I *know* is plain text
>>>> forces me to click something just in order to either view or save,
>>>> when saving after it's viewed is so simple anyway.
>>>
>>> Two of the reasons to why the patch was written in the first place
>>> are:
>>> - The Nagios CGIs are embedded in another GUI app that AJAX-load
>>> the CGI pages in a div element. To get a stand alone window that
>>> is possible to Ctrl+S save would mean a lot of tweaking, while the
>>> result would violate an otherwise smooth GUI.
>>>
>>> - Our users are no techies. An additional step would require a manual
>>> (yah, no kidding) that no one reads anyway. They just want to get
>>> the data directly into a spreadsheet with as little hassle as
>>> possible.
>>>
>>>>> Likewise, CRLF is used.
>>>>>
>>>>
>>>> This could be tricky. I know there are parsers out there that handle
>>>> the Nagios-style CSV format, and if they break because we suddenly
>>>> choose to go strict with the style we use, we shove a broomstick up
>>>> our asses for no gain what so ever.
>>>>
>>>> So... Have you verified that this patch doesn't break anything, or
>>>> is that supposed to be an exercise for one of the maintainers? If
>>>> you haven't done it, it's unlikely to get done at all, and in that
>>>> case the CRLF part of the patch will almost certainly have to be
>>>> dropped or modified so that line-endings are given as a character
>>>> sequence by the user instead.
>>>
>>> No, I have not run any additional tests. Just a normal compilation
>>> and our own in-house parser. Any specific parser/test you are thinking
>>> about? Hmm, I will try to look into a solution with desired line-
>>> ending supplied as a URI query variable that defaults to LF-only.
>>> Feel free to drop the CRLF part for the moment. I'll be back.
>>>
>>
>> I've done so. Since the only editor I know of that screws up LF/CRLF
>> differences in Windows is Notepad, I'm not overly fussed about this
>> and would rather just ignore it completely. I know all the major
>> office suites (Open, Libre and MS) handle LF line-endings just fine
>> in csv input though.
>
>
>
> I hear you. The patch is now revamped to listen to the user. By default
> nothing is changed.
>
> Summary:
> - CSV output is either as today, or strict compliant with RFC4180.
> No in betweens.
>
> - If the URI query parameter "csvstrict" is supplied together with
> csvoutput. The output will be strict according to RFC4180.
> - Otherwise, the output is the same as today.
>
> - An additional checkbox for csvstrict has been added
>
> - Output according to RFC4180 has the following changes compared to the
> traditional output: - HTTP, changed header: Content-Type: text/csv; header=present
> - HTTP, new header: Content-Disposition: attachment; filename=availability.csv
> - CSV, line-ending is CRLF
> - CSV, no spaces inside CSV fields
>
>
> Hope you like this better. The patch is against the 3.3.1 release.
>
This one duplicates all the
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]