The client currently uses XML-RPC. A XML-RPC error can contain nothing but an error code and a message. This prevents us from adding any additional information like the error's class name, warnings, log messages, or extra instructions on how to solve the error. This is limiting us now (see a workaround for instructions in commit 88262a7, or XML-RPC discussion http://www.redhat.com/archives/freeipa-devel/2012-October/msg00535.html), and will probably continue limiting us in the future.
The JSON format is much more flexible. (It's also a more modern standard.)
We should switch to JSON-RPC on the client now, and start deprecating XML-RPC, so that we can drop it in IPA 4.0+.
JSON is used in the Web UI, so support is already there, we just need to switch backends. Our tests use XML-RPC, so that path would still be fully tested for the sake of backwards compatibility.
If this gets accepted you'll need to open a bug against certmonger to have it switch to json as well (or you can do that independently). It uses the xml-rpc interface now.
If Certmonger won't need any of the extra info we will want to add (e.g. http://freeipa.org/page/V3/Messages), it can stick with XML for a few years. This is about deprecating it (i.e. no new features for XML-RPC), not removing it.
What about ipa-join, it would have to be switched to the JSON too. That would require a separate ticket and task. This however would allow us to drop dependency on the c-xmlrpc.
I think we'll need to provide the xml-rpc interface for quite time time even if we move away from it internally.
We'd need to investigate the C JSON libraries too, and make sure they are available in RHEL. Or I guess we could re-write ipa-join in python.
json-c is available so it is not a problem.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=887179
Reverting the Bugzilla clone operation, this was my mistake when testing Trac/Bugzilla synchronization tool.
I think this would be a change in the right direction, but as was said, we need to be sure that we have resources for this change and also that we have all the needed pieces in RHEL too.
We also need to be aware of increased resources needed for testing ipalib changes - we always need to make sure we did not break old clients still using XMLRPC interface. Such breakages would not be so obvious since we would have all clients using the new JSON-RPC interface.
Looking back, I see that I wrote this somewhat incorrectly. Dropping XML-RPC in IPA 4.0+ would be nice, but it's not needed. The client switch would still be useful by itself.
Note that because of capabilities (#2732), we need to start testing old clients anyway.
Replying to [comment:5 dpal]:
I wouldn't say not a problem. Having a package that provides the interface is good, but we'd still need to see if this fit our needs.
xmlrpc-c, for example, integrates directly with curl so we don't have to deal with HTTP, authentication, etc at all.
This is will be needed for messages (#2732), and that issue blocks several others in this bucket. I'll start working on this.
3.4 development was shifted by one month, moving tickets to reflect reality better.
Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.
master: 73b8047
Metadata Update from @pviktori: - Issue assigned to pviktori - Issue set to the milestone: FreeIPA 4.0 - 2013/11
master:
ipa-4-9:
Login to comment on this ticket.