Sorry about the verbosity on that one, will definitely keep it short and sweet in the future. :-) <br><br>I've been following the conversations at <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=398281">https://bugzilla.mozilla.org/show_bug.cgi?id=398281</a>:<br>
<br>I understand not wanting to provide more than one way of getting at bug information. What concerns me is the possibility that the concept of Bug.search may be overkill. Is there a need to provide an interface that mimics bugzilla's search? I know from a bugzilla developer's standpoint it's the natural approach... the more powerful the better. However, what do the potential users of the API really want? Do they need all that power? Or would a function for each use case suffice? ie...<br>
<br>   Bug.GetByUserId<br>   Bug.GetByProductId<br>   Bug.GetByStatus<br>   Bug.GetByPriority<br><br>or the overall encompassing call: Bug.GetByParams( UserId, ProductId, Status, Priority ). <br><br>With an approach like this would it solve the majority use cases? Again, I realize that a super powerful search feels great. Could it be overkill? I say this not really knowing the user base so I could be missing a huge part of the picture here.<br>
<br>Thoughts?<br>Scott<br><br><div class="gmail_quote">On Wed, Jul 2, 2008 at 4:31 PM, Max Kanat-Alexander <<a href="mailto:mkanat@bugzilla.org" target="_blank">mkanat@bugzilla.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


        Hey Scott! Wow, very detailed there. :-) No need to write quite<br>
that much, we're relatively informal--you're free to just say, "Hey, I<br>
think we should add X to Y, sound good?"<br>
<br>
        My responses below:<br>
<div><br>
On Wed, 2 Jul 2008 16:20:16 -0600 "Scott Saad" <<a href="mailto:saadsj@gmail.com" target="_blank">saadsj@gmail.com</a>> wrote:<br>
> and a query for bugs by product would be very helpful.<br>
<br>
</div>        The problem is that I don't want, in the future, two ways to do<br>
the same thing--that can be pretty confusing. Bug.search (or whatever<br>
we're calling it) will get that information for us, so I don't want to<br>
add another way to get it. We can't remove functions once we add<br>
them--that breaks the API--so we have to be careful about what we add.<br>
<div><br>
> * Expand the WebService:Bug class to include a more complete set of<br>
> fields. This would mean including data like, status, assigned_to,<br>
> priority, severity, etc.<br>
<br>
</div>        Sure, that'd be good. I already have a patch that does that<br>
somewhere, I might have even attached it to a bug.<br>
<br>
        -Max<br>
<font color="#888888">--<br>
<a href="http://www.everythingsolved.com/" target="_blank">http://www.everythingsolved.com/</a><br>
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.<br>
-<br>
To view or change your list settings, click here:<br>
<<a href="http://bugzilla.org/cgi-bin/mj_wwwusr?user=saadsj@gmail.com" target="_blank">http://bugzilla.org/cgi-bin/mj_wwwusr?user=saadsj@gmail.com</a>><br>
</font></blockquote></div><br>