On Sep 22, 2011, at 8:51 AM, Richard W.M. Jones wrote:
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.
The alternative is to use something like traditional C or Python escaping. Like\040This,
and just escape the characters that require it.
> * 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