SOAP

[Myk Melez]

Jim Walters wrote:

>Anyway, there are a bunch of things to figure out
>
>- Which APIs to implement
>  
>
All of them!  I'd start with authentication and authorization, since 
you'll need to have that for everything else.  After that the big two 
are searching for bugs and retrieving a specific bug, closely followed 
by submitting a bug and updating an existing bug.  It goes on from there.

>-  What to do when I run up against Bugzilla library functions which are
>"close but no cigar" when it comes to being used within the SOAP library
>(an initial look at implementing a simple show_bug&id=1 function
>indicates this may happen occasionally)
>  
>
Fix 'em!

>- General philosophy on API arguments but more specifically return
>values (thin, heavy, complex, simple)
>  
>
API arguments should make sense.  I'm not 100% sure what you are asking 
about return values, but I think the answer is that it varies.  The API 
should be able to provide all the data available, or at least all the 
data that the current web interface provides.  In cases where only a 
subset of data is regularly required, however, it should be able to 
retrieve and return just that subset.

>- Need to learn Perl better in order to know whether I really need to
>resolve namespaces with things like Bugzilla::DB:ConnectToDatabase() all
>the time.
>  
>
See "use":

http://www.perldoc.com/perl5.8.0/pod/func/use.html

>The nice surprise was the SOAP support in Mozilla. It will give me a
>chance to play with XUL widgets along the way.
>  
>
Over in Bugxula I'm building a XUL client for Bugzilla:

http://bugxula.mozdev.org/

If you'd like to contribute to this project, please do!

-myk