Bug 428498 - xmlrpc.cgi compatability with the upstream
xmlrpc.cgi compatability with the upstream
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: WebService (Show other bugs)
3.2
All Linux
high Severity high (vote)
: ---
: ---
Assigned To: Noura El hawary
:
Depends On:
Blocks: 406131 427053
  Show dependency treegraph
 
Reported: 2008-01-12 02:23 EST by Noura El hawary
Modified: 2013-06-24 00:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-25 17:13:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Noura El hawary 2008-01-12 02:23:49 EST
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 17:17:25 EST
(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-15 22:45:12 EST
(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-15 23:07:41 EST
And that's not part of the stock standard XMLRPC interface?
Comment 4 David Lawrence 2008-01-15 23:35:40 EST
(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 17:13:54 EST
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.

Note You need to log in before you can comment on or make changes to this bug.