[libvirt] [PATCH v3 04/18] conf: Rework parsing in virStoragePoolDefParseSourceAdapter

Laine Stump laine at laine.org
Tue Mar 14 19:08:18 UTC 2017


On 03/14/2017 02:30 PM, John Ferlan wrote:
>
> On 03/11/2017 08:16 PM, Laine Stump wrote:
>> On 03/10/2017 04:10 PM, John Ferlan wrote:
>>> Rather than use virXPathString, pass along an virXPathNode and alter
>>> the parsing to use virXMLPropString.
>> Just so I understand the reasoning correctly - you're not doing this so you can use virXMLPropString() instead of virXPathString(), but just so you can remove the "adapter" from the path to each attribute (and in the cases where that turns a "path" into simply the attribute name, you're switching to virXMLPropString() because it's presumably slightly more efficient. Right? Or is there some other reason you prefer virXMLPropString()?
>>
> Missed this on the first pass through your review... Probably because
> your email client has stopped believing in line wrapping or my client
> isn't seeing some setting properly <sigh>


Really? Oh %&*()%$*)%$...

Late last week I encountered messages from someone which, when replied to, led to all of *their* quoted paragraphs in the reply each being a single very long line. So I asked about it on IRC, and Dan pointed me to some webpage claiming to know how to "fix" Thunderbird so that it worked reasonably with git-generated emails. I made the suggested changes, it didn't help, and then *I thought* I changed everything back. Apparently not :-(


>
> I had originally wanted the ability to just parse an <adapter...> since
> that was how this would be represented in the domain; however, even
> though that got mothballed - I still felt what I'd done so far was at
> least a step up in readability, flow, etc. over what was there before.

Okay, so even more reason than what I'd assumed, i.e. more than enough :-)




More information about the libvir-list mailing list