Status

On mozilla.support.bugzilla Thorsten Schöning wrote:

Still how does one get this Bugzilla::Webserves::Bug?

There are different ways of course, one is BZ::Client, others depending on your environment may exist or you need to create your own client or whatever.

Name a way then. You see when I say BZ::Client I can do cpan BZ::Client and I will get downloaded actually code that I can run (It's pretty clear I'm workign in Perl no?). However when I say Bugzilla::Webservice::Bug I cannot do cpan Bugzilla::Webservice::Bug and get code because cpan says it can't find anything listed under Bugzilla::Webservice::Bug. Now I know that it's not part of CPAN so what is it part of and how do I get the code?

'Cause you just got through telling me that BZ::Client is not an official Bugzilla project and yet you pointed me to specifically to http://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService/Bug.html#search which is in bugzilla.org. Was I not to think that that would be "an official Bugzilla project"? Yet there's nothing there that I can see about getting that code!

Looking at https://wiki.mozilla.org/Bugzilla:Addons#Client_libraries_for_the_Bugzilla_Webservices.2FREST_API I see it telling me to use BZ::Client (and not even mentioning BZ::Client::Bug, which is much more to the point)

Because the wiki can't know your use case. :-)

Looking at CPAN for BZ::Client (http://search.cpan.org/~jwied/BZ-Client-1.04/lib/BZ/Client.pm) we have the following methods:

new
url
user
password
login
api_call

Not exactly a bastion of functionality! The Wiki could anticipate that I might need a bit more functionality for any functional use case! Just my opinion of course :-).

Looking at BZ::Client::Bug (http://search.cpan.org/~jwied/BZ-Client-1.04/lib/BZ/Client/Bug.pm) I see:

CLASS METHODS
get
new
create
search
INSTANCE METHODS
id
alias
assigned_to
component
creation_time
dupe_of
is_open
last_change_time
priority
product
resolution
severity
status
summary

At the very least, couldn't the wiki mention both?

for a client side solution. I guess I didn't mention I'm working client side. Actually I see little difference between client and server side API's here.

That sounds like one of the design goals of BZ::Client, but I'm only guessing.

You mean a design goal to work on more than one machine? I'd say it's basic functionality but perhaps that's just me.

I want the API that can get me the Bugzilla data from wherever I happen to run it. Oh and I'm working in Perl.

I don't think I understand this paragraph, BZ::Client works wherever your client is able to access your Bugzilla from. But your problem is totally different, you want functionality that may or may not be provided currently by the WebService-API. Check the docs and if it's not sufficient check the code and maybe provide patches for the docs for anyone else with a similar problem.

It looked like you were telling me that BZ::Client was not an official project and that I shouldn't be using it. I realize you were saying that I'd be better off contacting that module's owner, and I have (have not heard back yet). It's just I thought there would be some sort of official or at least full featured way to access the functionality of Bugzilla from scripts, specifically Perl scripts as from what I can tell Bugzilla is largely written in Perl. And as it is quite old in Internet terms I find it surprising there isn't a full featured Perl module that everybody's using already.

So far I've found WWW::Bugzilla and things like WWW::Bugzilla::Bugtree and WWW::Bugzilla::Search. These use some sort of WWW::Mechanize thingy and seems to be horribly inefficient. For example, the new method requires a bugid and takes a while to instantiate. If a script had to process a 1000 bugs and instantiate each one of them at like 4-5 second per instantiation it would take just way too long to get anything done. The Search module's no better. If you have a couple of thousand bugs qualifying then it gathers all of the data, returns a huge structure and takes tens of minutes to return from the search call. I emailed the author about this module but haven't received a response.

I then found BZ::Client and BZ::Client::Bug, which work fairly decently. It's quicker and pretty flexible but got stopped at the lack of search capability.

I see this Bugzilla::Webservice::Bug but have no idea on how to download the code.

I also see this BzAPI thing but it appears to be server side only.

One thing I'm trying to accomplish: We have a number of saved searches. One process we have here executes a number of these and saves the results to .csv files. This is done manually through the web UI. Another Perl script gathers a bunch of these .csv files and produces another .csv file in the form of a report that is useful to management. I'd like to change this Perl process to simply interrogate the Bugzilla database directly, possibly utilizing the saved searches directly and produce the final .csv file directly (or perhaps make a web page instead). There are also many other scripts I could imagine Perl doing by having full functioned access to Bugzilla.

Oh and I checked BZ::Client::Bug::search's code. It descends off in to a plethora of web related technologies that sufficiently obscures what's going on, what's expected and what works WRT search.

I for example simply don't use the WebServices and therefore can't tell you if your needed behavior is implemented or not.

I don't particularly care if it's WebServices or not. I just want to interact with the functionality of Bugzilla programmatically through Perl. The backend can be WebServices, client/server socket stuff or a direct API.

Indeed. I've worked with 2 REST APIs so far and they both shared the characteristic of 1) being poorly documented

I don't find the WebServices API of Bugzilla documented that poorly,

Starting from http://www.bugzilla.org/docs/4.4/en/html/api/index.html it's not immediately clear that this is a server side only technology. If it's not a server side only technology then it's not at all clear how to get the client side code. And there's an appalling lack of real world examples.

if it is you are in a happy position because you just need to check the implementation and provide patches to improve the docs, because your behavior is already implemented.

You make the incorrect assumption that 1) I understand enough about the code base to make contributions, 2) I have that time and 3) I wish to work for free. I'm a consultant and I need to get stuff done for my client. My client does not pay me to work on open source projects. I'm not totally opposed to working on open source projects nor contributing to them but I don't have the time nor inclination to do so here. Sorry.

If it is not your have a bigger problem because your functionality needs implementation. :-)

Not necessarily. Somebody else could have already implemented this or there may be another solution. That's why I'm posting here. I'm shocked that such a mature technology has such a lack of an interface, supported or not...

and 2) not supporting full search. What's up with that?

As often it's a matter of available resources.

I see it as more of a matter of professionalism. I know that I would not release code, open source or not, unless it was not at least reasonably feature complete.

REST APIs seem, in my experience, to use too much web technologies and vagueness, attempting to be language agnostic, that they read as if they say nothing and you need to go elsewhere for answers to simple questions. There's never any good examples of real code, they often don't describe what data is returned other than to say that it's of XML or JSON format - how are multiple records indicated? How empty fields handled? Different field data types? How are exceptions handled? These questions are often not answered. And usually the search portion is "not totally implemented". I think that this is because representing search conditions appears to be difficult to do in a REST scenario (largely because they seem to try to represent the search in terms of data structures like XML instead of simply strings that must be parsed - REST APIs seem to eschew conditional parsers).