Gluster users - Aug 2015 - [Gluster-devel] Non-Uniform opErrstr output in all gluster --xml commands

Having (null) is not common in xml convention. Usually, it's either

<opErrstr/>

or

<opErrstr></opErrstr>

Regards,
 -Prashanth Pai

----- Original Message -----
> From: "Avra Sengupta" <asengupt at redhat.com>
> To: "Atin Mukherjee" <amukherj at redhat.com>,
"Gluster Devel" <gluster-devel at gluster.org>, gluster-users at
gluster.org,
> kauffman at cs.uchicago.edu, "Dusmant Kumar Pati" <dpati at
redhat.com>, "Shubhendu Tripathi" <shtripat at redhat.com>,
> msvbhat at redhat.com
> Sent: Wednesday, August 5, 2015 3:16:10 PM
> Subject: Re: [Gluster-devel] Non-Uniform opErrstr output in all gluster
--xml commands
> 
> On 08/05/2015 03:06 PM, Atin Mukherjee wrote:
> >
> > On 08/05/2015 02:58 PM, Avra Sengupta wrote:
> >> Hi,
> >>
> >> As reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1218732, in
> >> the event where there is no opErrstr, some gluster
commands'(like
> >> snapshot status, volume status etc.) xml output shows
> >> "<opErrstr>(null)</opErrstr>", while other
commands show just
> >> "<opErrstr/>". This non-uniform output is
troublesome for people who
> >> parse this.
> >>
> >> IMHO showing "<opErrstr>(null)</opErrstr>"
is much more descriptive. I
> >> would like to propose making sure all commands follow this uniform
> >> approach, instead of displaying just
"<opErrstr/>".
> > Makes sense to me as long as its uniform. However the existing ones
> > which follow "<opErrstr/>" need change in parsing
logic :
> To attain uniformity, one or the other parsing logic will break. we
> might as well get it right for once.
> >> Regards,
> >> Avra
> >> _______________________________________________
> >> Gluster-devel mailing list
> >> Gluster-devel at gluster.org
> >> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>

In that case will stick with <opErrstr/> for all the null elements.

On 08/05/2015 04:10 PM, Prashanth Pai wrote:
> Having (null) is not common in xml convention. Usually, it's either
>
> <opErrstr/>
>
> or
>
> <opErrstr></opErrstr>
>
> Regards,
>   -Prashanth Pai
>
> ----- Original Message -----
>> From: "Avra Sengupta" <asengupt at redhat.com>
>> To: "Atin Mukherjee" <amukherj at redhat.com>,
"Gluster Devel" <gluster-devel at gluster.org>, gluster-users at
gluster.org,
>> kauffman at cs.uchicago.edu, "Dusmant Kumar Pati" <dpati
at redhat.com>, "Shubhendu Tripathi" <shtripat at
redhat.com>,
>> msvbhat at redhat.com
>> Sent: Wednesday, August 5, 2015 3:16:10 PM
>> Subject: Re: [Gluster-devel] Non-Uniform opErrstr output in all gluster
--xml commands
>>
>> On 08/05/2015 03:06 PM, Atin Mukherjee wrote:
>>> On 08/05/2015 02:58 PM, Avra Sengupta wrote:
>>>> Hi,
>>>>
>>>> As reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1218732, in
>>>> the event where there is no opErrstr, some gluster
commands'(like
>>>> snapshot status, volume status etc.) xml output shows
>>>> "<opErrstr>(null)</opErrstr>", while
other commands show just
>>>> "<opErrstr/>". This non-uniform output is
troublesome for people who
>>>> parse this.
>>>>
>>>> IMHO showing
"<opErrstr>(null)</opErrstr>" is much more descriptive. I
>>>> would like to propose making sure all commands follow this
uniform
>>>> approach, instead of displaying just
"<opErrstr/>".
>>> Makes sense to me as long as its uniform. However the existing ones
>>> which follow "<opErrstr/>" need change in parsing
logic :
>> To attain uniformity, one or the other parsing logic will break. we
>> might as well get it right for once.
>>>> Regards,
>>>> Avra
>>>> _______________________________________________
>>>> Gluster-devel mailing list
>>>> Gluster-devel at gluster.org
>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>