Re: [mantisbt-dev] Mantis 2.0.x vs 'next'

[Robert M. <rob...@gm...>]

Hi Paul,

I'll just discuss the SOAP API for now.

On Sun, Nov 4, 2012 at 5:40 PM, Paul Richards <pa...@ma...> wrote:
>
> "therefore intentionally not included some commits to master, not to mention
> dumped the soap api entirely" -> a) there's a couple of changes in master
> that do not make sense. For example, if you look at daryn's original work to
> re-organise the mantis file layer - that negates about 3 commits to master
> that deal with out we calculate paths correctly or incorrectly in some
> cases. In terms of the 'soap api' - I consider that as temporary. The
> current soap api 're-implements' too much of the mantis code base, only
> supports soap and was written *before* mantis supported multiple
> projects/configs etc - and whilst it works, and rombert has done a great job
> of improving it -  It's also fairly high up on the list of things in mantis
> that needs to be looked at from scratch. For 3 reasons:
>
> a) a number of other projects now support multiple webservice layers
> (rest/soap/xmlrpc). There's a few projects out there, and even the zend
> framework that allow you to organise things in such a way that you can have
> a webservice class that can output soap/rest/xmlrpc as required depending on
> the client.  I know dhx has reservations about that sort of approach.
> Rombert's probably in a better position to see if that sort of approach is
> likely to work.
> b) the webservice layer should be a loose wrap-around mantis - when i last
> looked there were some places it had to do db queries due to how mantis
> currently works.
> c) some of the calls I think still need updating to support multiple
> projects/configs - For example, mc_enum_status - I believe you can't specify
> a user/project id.

I completely agree that the SOAP API as it is reimplements too much
stuff. I've been giving some thought about how to remove this
duplication and I think it comes down to making sure that

- there is a clear, high-level core API available in MantisBT which
exposes the required operations, e.g. report a bug, with validation,
history recording, security checks, notifications etc done out of the
box
- that core API is usable out-of-the box by the SOAP API and other
alternative implementations, like for instance a JSON API

I would however do this incrementally, rather than from scratch, for
two reasons:

1. I think that the overall approach to the soap api is correct, and
we only need to fix some things, mainly
 - remove all inline SQLs and use API calls
 - only handle errors by trigger_error ( or whatever the next version brings )
2. The risk of regression is too high when rewriting everything.

I would like for 1.3.x to be able to create a SQL-free SOAP API and
perhaps add an additional JSON API which can be used for mashups and
rich interactions.

Just to drop an idea as one of the nicer 1.3.x feature, imagine a JSON
API which is able to validate a submitted bug and display errors
inline . No more back button :-) Of course, we'd fall back to plain
form submissions if Javascript is not available.

Robert

--
Sent from my (old) computer