Bug 428498

Summary:	xmlrpc.cgi compatability with the upstream
Product:	[Community] Bugzilla	Reporter:	Noura El hawary <nelhawar>
Component:	WebService	Assignee:	Noura El hawary <nelhawar>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	3.2	CC:	dkl
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-11-25 22:13:54 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	406131, 427053

Description Noura El hawary 2008-01-12 07:23:49 UTC

Currently in our rh_bugzilla_2_18 xmlrpc.cgi has class bugzilla that
incorporates all the RPC modules , so to call an xmlrpc function we call it
using the bugzilla class no matter which RPC module it is located under, exmaple
"bugzilla.getBug",
however in the upstream bugzilla every function is called using the module it
exists under so get_bugs() is under Bug.pm so it will be called "Bug.get_bugs".

for our upgrade how should this work, as changing it I guess will affect a lot
of people's xmlrpc scripts. 

Also ,I guess we need to conribute the subroutine multicall in our xmlrpc.cgi to
the upstream.

Comment 1 Kevin Baker 2008-01-15 22:17:25 UTC

(In reply to comment #0)
> for our upgrade how should this work, as changing it I guess will affect a 
lot
> of people's xmlrpc scripts. 

Yes. We will break a lot of people's scripts. But we will send out many many 
many warnings before the cut over date. We we also assist people to change 
their scripts over. The reason we go to all that effort is so that everyone 
gets standardised on the upstream xmlrpc interface. We save as we won't have 
to support it ourselves anymore.
 
> Also ,I guess we need to conribute the subroutine multicall in our 
xmlrpc.cgi to
> the upstream.

What does that do?

Comment 2 David Lawrence 2008-01-16 03:45:12 UTC

(In reply to comment #1)
> > Also ,I guess we need to conribute the subroutine multicall in our 
> xmlrpc.cgi to
> > the upstream.
> 
> What does that do?
> 

system.multicall allows you to chain a list of XMLRPC methods inside a single
XMLRPC call instead of sending them separately. It returns a list of returned
data structures.

Comment 3 Kevin Baker 2008-01-16 04:07:41 UTC

And that's not part of the stock standard XMLRPC interface?

Comment 4 David Lawrence 2008-01-16 04:35:40 UTC

(In reply to comment #3)
> And that's not part of the stock standard XMLRPC interface?

It's not currently part of the 3.2 upstream WebServices API but it is 
part of the XMLRPC standard. I implemented it from scatch a while back
but it should be using the standard call and return structures.

Comment 5 David Lawrence 2008-11-25 22:13:54 UTC

I think this is not an issue now since we are supporting the compat_xmlrpc methods and moving people to the new 3.X API when possible. Also we have implemented system.multicall in the compat_xmlrpc api.