client-server

[linas@linas.org]

It's been rumoured that Tyson Dowd said:
> If you can open a socket, send out the right
> headers, and spit out some XML, you can do SOAP.

right, that's the big apeal behind soap. ...

> The problem seems to be that C is insufficiently reflective to be able
> to do an easy implementation (e.g. Perl and Python).  These languages
> can easily serialize their own data structures into (say) XML, and then
> de-serialize.  So it's easy to write a generic SOAP interface for them.

right.  Does this mean that a C binding for soap would need to use
IDL's in order to understand what to marshal?  Hmmm ...

> But since gnucash can already marshall it's important data to and from
> XML, you really only need a socket library or a http library.

right, except we already got one (gnome's libghttp).

> Infrastructure implies some sort of overarching, bulky system.  I would
> say instead that SOAP is a cookbook for doing RPC using HTTP and XML.

right, that's again the big draw behind soap.  It seems to solve 
a lot of the problems that e.g. sun-rpc and corba have running over the
open internet.  And xml-schema seems to tackle the idiotic lack of
typing that DTD's have (and thus made xml-rpc and other xml-to-language
bindings hard to do).

btw, found a nice faq at 
http://www.develop.com/soap/soapfaq.htm

> If you want to write *whole language* bindings or need the equivalent of
> IDL, then you start to develop infrastructure.  

well, I can always 'roll my own' xml-http protocol without too much
hassle, so I assume the selling point of soap is precisely the 'whole
language infrastructure' thing ... precisely what I thought m$ is
advertising.

> As opposed to the roll-your own technology, 

the point being that the roll-our-own technlogy is 'virtually finished'
in some suitably virtual sense.

------
I skimmed the soap spec, and I think it might be worth the effort to 
make our xml file format more 'soap-like' & e.g. make sure we use
xml namespaces & etc.

--linas