User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060731 Ubuntu/dapper-security Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20060731 Ubuntu/dapper-security Firefox/188.8.131.52 The new WebService interface developed to Bugzilla on bug 224577 uses the XML-RPC protocol. By the way, only a few lines of code need to be changed to make it work with SOAP (or both) because it uses the SOAP::Lite package. I don't know if the Bugzilla comunity is intrested in using both SOAP and XML-RPC protocols (is it?), but as long as I need to implement this to my university project, I will attach in this bugs the diffs to make it work with SOAP if someone is interested. I will atach a patch I already have that make the existing interface work with both SOAP and XML-RPC. Reproducible: Always
Created attachment 238680 [details] [diff] [review] Add SOAP support (not using WSDL yet) I tested this with clients in php and perl. I will attach they too.
Assignee: general → michetti
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Bugzilla 3.0
I don't know that I'm particularly interested in including SOAP support in Bugzilla 3.0, or at all. The reason is primarily that this is an API, and we have to keep the *output* formats exactly the same. And with two APIs, we'd have to keep them the same between both. Also, SOAP is much more complex, and although on the *code* side of things the changes are simple, the considerations in maintaining a SOAP interface (such as providing a WSDL for consumers) are much more complex.
(In reply to comment #3) > I don't know that I'm particularly interested in including SOAP support in > Bugzilla 3.0, or at all. > > The reason is primarily that this is an API, and we have to keep the *output* > formats exactly the same. And with two APIs, we'd have to keep them the same > between both. I agree that having two API's is not so common, but I believe that we will not have so much problem in keeping the output the same. The patch I attached use the same modules XML-RPC uses, so if you build a new module for one, it will also work for the other. > Also, SOAP is much more complex, and although on the *code* side of things the > changes are simple, the considerations in maintaining a SOAP interface (such as > providing a WSDL for consumers) are much more complex. > The complexity in the SOAP protocol is due to the number of functionalities it can provide, but if you use only the basic functionalities, it is as easy as the XML-RPC. And also, the modules available to work with SOAP hides the complexity with the protocol. I also agree that providing WSDL for consumers can be a lot of work, but there are some tools available that can make things easier, like this CPAN module: http://search.cpan.org/~pdenis/WSDL-Generator-0.02/lib/WSDL/Generator.pm I'm not experienced with it, but it looks like we can use it to create WSDL files automaticaly from the modules that will be implemented for the XML-RPC API anyway. The only problem is that it is very new... WSDL can also make things easier for people who are not experienced with PERL or Bugzilla, because they can read it and understand how to use the service. So, my point is that although SOAP can be more complex, it enables the use of more advanced features and also make things easier for users in some situations. I believe that if we also use SOAP, Bugzilla would be used in more complex situations like in the development of SOA systems for example (which is my case). We can use this bug to see how difficult it realy is to keep XML-RPC and SOAP working together and also discuss in which situations the SOAP functionalities could be useful, and then decide what to do with it. What do you think?
(In reply to comment #4) > [snip] What do you think? Well, I think you have a lot of good points! What I'd really like to do is get out an XML-RPC interface in a stable release (3.0), and then after we have some real world experience working with just the XML-RPC interface, we can look at possibly including a SOAP version for 3.2. I'm not totally against it, I'd just like to wait until after we have a fully stable XML-RPC interface that's been really used, and we have some feedback on what people are looking for in an API. I mean, heck, maybe starting with 3.2 we'll have a SOAP-only interface, if that's what people really need. But I'd like to see what the general user reaction is to the API as just an XML-RPC API, before we make any decisions in that area.
In no way should we mark this bug as wontfix. If we get several requests about supporting SOAP, then that's something we should do. Also, I'm not entirely sure we should wait to have a stable API before supporting SOAP. In the worst case, this could go in contrib/ for 3.0.
> Well, I think you have a lot of good points! > > What I'd really like to do is get out an XML-RPC interface in a stable > release (3.0), and then after we have some real world experience working with > just the XML-RPC interface, we can look at possibly including a SOAP version > for 3.2. So what is the next step in the XML-RPC API development? Are there any other structural things to be developed or we just need to add new functionalites to the API? I need to implement at least some simple SOAP interface because we have a deadline on my university project... anyway a friend of mine (Vinicus Baggio), who is also in this project, will help me developing this SOAP API, and we agree that if you prefer, we can start by implementing some of the functionalities, like post comment or create new bug, because they would work for both APIs. What you think? We would need some help to decide which functionalitites should be implement first though. Could you help us on that? Or point someone who can? Vinicius already implemented a post comment functionlity... should we create a new bug for each new functionality? We also have some doubts about which values should be passed as parameters, for example, to create a new bug, you need to specify the product and component. We should provide the product and component IDs or the names? We think we should provide the ID, but this information is not available throw the Bugzilla web interface... Any suggestion? Thanks for you help.
(In reply to comment #7) > So what is the next step in the XML-RPC API development? Are there any other > structural things to be developed or we just need to add new functionalites to > the API? Basically, everything about the way its implemented needs to change, except the basic framework. You can search for bugs with "webservice" in the title to see what we're doing. That should also answer all your other questions. And look through the archives of developers -at- bugzilla.org for "Webservice" to see our discussion there, also.
The trunk is now frozen -> TM: ---
Target Milestone: Bugzilla 3.0 → ---
I've been exposed to the need for WSDL lately: SAP is on the one hand able to generate proxies from WSDL, and gives on the other hand a really hard time to utilize XML-RPC. The result that the SAP system I'm looking at will now stay without a Bugzilla connection, which is sad. I'm told Java benefits greatly from WSDL, too.
(In reply to comment #10) > I've been exposed to the need for WSDL lately: SAP is on the one hand able to > generate proxies from WSDL, and gives on the other hand a really hard time to > utilize XML-RPC. The result that the SAP system I'm looking at will now stay > without a Bugzilla connection, which is sad. > I'm told Java benefits greatly from WSDL, too. Hmm. Those are all good use cases. I just don't want to maintain the WSDL by hand, really, and thanks to the way Perl is, I doubt it can auto-generate WSDL in any reasonable fashion.
So, now that we're going to switch to RPC::Any, the best way to get SOAP support into Bugzilla would be to get SOAP support into RPC::Any. That would make this pretty simple.
Depends on: 475086
(In reply to Max Kanat-Alexander from comment #12) > So, now that we're going to switch to RPC::Any, the best way to get SOAP > support into Bugzilla would be to get SOAP support into RPC::Any. That would > make this pretty simple. In 6.0 we will only be supporting REST and dropping support for XMLRPC and JSONRPC. With that, SOAP support is definitely not going to be implemented. dkl
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.