On 02/24/2012 12:09 PM, Martin Kosek wrote:
On Fri, 2012-02-24 at 11:09 +0100, Petr Viktorin wrote:
...
You need four backslashes for a literal backslash, three to escape a
comma. I think 2.1 clients are already broken, and the backwards
incompatibility would only affect workarounds.
>
Yes, but CSV values without escaping works. And this IMO covers 99% of
user cases, especially given the fact that escaping is that difficult to
use. Users can simply not use characters that need escaping.
CSV values without backslashes and initial double quotes would not be
affected at all.
We cannot break commands like this one:
ipa dnsrecord-add example.com foo --a-rec=10.0.0.1,10.0.0.2
ipa user-mod --phone=555-1234,555-6789
I also don't want to break commands like this:
ipa [...] --a-rec=10.0.0.1,10.0.0.2 --a-rec=10.0.0.3
I would be OK with changing CSV formatting if it supports both ways:
1) Plain arrays from new clients where CSV parsing is done just once
(only on clients)
Old clients *already send* plain arrays; but the server currently
errorneously parses each part again. Maybe a better fix for now would be
to set the "don't parse again" flag on the XMLRPC receiving code,
instead of the client. That way old and new clients would behave
identically.
2) CSV value which is then parsed on the server
Is there any reason at all to do CSV parsing on the server, for the
CLI/XMLRPC case? I can't see it.
---
Petr³
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
