XML API for LegerSMB

["Christopher Murtagh" <..hidden..>]

On 9/26/06, Tony Fraser <..hidden..> wrote:
> I'll be one of the first to help out to create an open reusable API for
> LedgerSMB and WWW::Mechanize has no place in such an API. Defining such
> an API and changing the web interface of LedgerSMB to use the API is
> something I think should be high on the priority list. I think that this
> is one of the first steps that needs to be done on the road to making
> LedgerSMB into the infrastructure program it should be. Someone's going
> to have to convince me that this API should be XML based though, I'm not
> on the XML bandwagon yet.

(Creating new thread for this topic)

 I agree that changing LedgerSMB's UI is a fairly important task as
well, although it will be a difficult one, mostly because there is a
lot of business logic tied into the current display logic.

The advantages I can see to using XML:

- It is the de facto preferred way to send structured data these days.
Some of this is marketing, another part of this has real value. The
marketing part means that if LedgerSMB is using XML, it's conforming
to well accepted standards. The 'real value' part is that there are a
lot of existing and mature tools to handle XML and associated
protocols which helps save some work.

- By sending a PO as an XML document, it can be first validated
against a DTD. This is only one step in validating/untainting the
data, but at least it checks that the data structure is valid. This
way, if the system were to change in some way, it would be easy to
catch older/incompatible documents being sent to it. And validating an
XML doc against a DTD is very easy with existing libraries.

- There are a couple of ways of using XML and accepting POs (for
example). Three that I can think of off the top of my head are (in
decreasing complexity): 1) SOAP 2) XML-RPC or 3) a simple HTTP POST of
an XML PO.  For the purposes of LedgerSMB, these methods differ
slightly and each have their advantages/disadvantages. For example,
SOAP has a lot more CPU overhead and is more complex, but is an easy
way to have a single interface for all transactions. XML-RPC is
simpler, but is getting trumped a bit by SOAP in the marketing
department. The HTTP POST of an XML document is by far the simplest
thing to code, but other than accepting XML it isn't really a
standard. So, I don't think picking any one of these would be a
disaster, but it should be thought out a bit before making that
commitment.

One thing that we could conceivalby do is after the XML interface is
done, we could rebuild the current UI to be a layer on top of it. This
is quite a long way away though.

Cheers,

Chris