Re: So what do SOAP and XML-RPC buy you?

[Ken MacLeod <ken@bitsko.slc.ut.us>]

Stuart Naylor <indtec@eircom.net> writes:

> When I go to the library I select a couple of books and return
> home. It would seem that you are intent on breaking my back with
> taking the whole library back home so I can select my reading
> matter.  After my selection of books and probably the required
> traction I can then return the library.
> 
> RPC and API technologies are essential in off loading transaction
> weight.  Currently 'content' as a total understatement is a tad to
> inefficient and broadening that scope is a ridiculous statement.
> Even with Moores Law we will have to wait for far to long before we
> can kill the problem with hardware.

The size of the HTTP content isn't really a distinction.  "RPC" or
"API" don't necessarily imply "small transactions" and "XML over HTTP"
doesn't necessarily imply "large transactions".  "XML over HTTP" in
this context is not meant to imply only transferring XML "documents"
(or any big chunks of XML).

> [list of RPC/API-based initiatives, systems, or projects]

> The above range from souped up EDI to WAP enabled ring tone tune
> down loaders and I am not saying they are great. They are solutions
> to problems but don't say they are bad until you have a better
> method.

They are not inherently "bad", but there are identifiable risks that
exist regardless of whether other solutions are yet available that do
not share the same risks (or have different risks).  When different
methods are available, then the common person will be able to decide
which set of risks they choose to accept.  In any case, it is still in
everyone's best interest to identify risks and to foster effort to
reduce risk.

  -- Ken