Libguestfs - Sep 2011 - [PATCH 0/1] Base64-encode non-printable data

I expect this patch to require a second version.  I mainly wanted to
spur discussion:
* I firmly believe hivexml needs more encoding checks before printing.
Base64 encoding made the most sense as hivexml already uses it
elsewhere.  Is this the right direction to go, to escape non-printable
data?
* Should there be an enumeration for encoding decisions?  I'm returning
strings because it felt a little like over-engineering for something I
could just see as having two values.
* There need to be at most two encoding descriptors for a values and
one for nodes.  Keys and values might need to encode their names.
Values might also need to encode their data.  We already know I'm
pushing for value data to go into attributes in another patch series.
Could we change the "encoding" value attribute to
"value_encoding"?
* I'd like to change values' "key" attribute to
"name" attributes.
Rich, what are your feelings, or what are the policies to which you're
adhering, on changing the name of an element that hivexml has already
been producing?  You've been quite accepting of new functionality coming
in, but what about renaming what's present?

--Alex


Alex Nelson (1):
  hivexml: Base64-encode non-printable data

 xml/hivexml.c |   75 ++++++++++++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 64 insertions(+), 11 deletions(-)

-- 
1.7.4.4

On Fri, Sep 16, 2011 at 09:30:00PM -0700, Alex Nelson
wrote:
> I expect this patch to require a second version.  I mainly wanted to
> spur discussion:
> * I firmly believe hivexml needs more encoding checks before printing.
Certainly agree with that.
> Base64 encoding made the most sense as hivexml already uses it
> elsewhere.  Is this the right direction to go, to escape non-printable
> data?
Base64 is a bit of a pain for consumers to handle.  I don't really
know what the alternatives are though.
> * Should there be an enumeration for encoding decisions?  I'm returning
> strings because it felt a little like over-engineering for something I
> could just see as having two values.
>
> * There need to be at most two encoding descriptors for a values and
> one for nodes.  Keys and values might need to encode their names.
> Values might also need to encode their data.  We already know I'm
> pushing for value data to go into attributes in another patch series.
> Could we change the "encoding" value attribute to
"value_encoding"?
>
> * I'd like to change values' "key" attribute to
"name" attributes.
> Rich, what are your feelings, or what are the policies to which you're
> adhering, on changing the name of an element that hivexml has already
> been producing?  You've been quite accepting of new functionality
coming
> in, but what about renaming what's present?
I don't have any preferences for hivexml.  It's broken and deprecated
at the moment, so make whatever changes are needed to make it working
and useful.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v