client-server

[linas@linas.org]

It's been rumoured that Tyson Dowd said:
> 
> 
> I think this approach is very interesting...  

I personally am very excited by it; it solves infrastructure problems 
with various well-known, well-understodd technologies (i.e. apache)

> way these kinds of technologies have been changing lately and I've
> noticed three things I think are really cool:
> 
> 1. XML/SOAP (what Microsoft is calling "web services") to provide
> distributed RPC like services.  This does much the same job as CORBA,
> but uses technologies that can be re-used elsewhere easily, and so have
> a low maintenance cost and a produce a lot of synergy (HTTP and XML).
> This can also take out a *lot* of the nastiness of cgi-bin, since you
> can just often just request information you want as if you were making a
> normal function call (well, ok, perhaps a bit more trouble).

ok, sladshdot gave a pointer to a perl module that does soap.
Now, how about a c-language, shared lib .so  for linux implementation
of soap?  Given how much of gnucash is in C (viz, especially the
engine), I'd like to have a 'native' soap.

> 2. XML/HTML with special embedded <objects> that rely on a particular
[...]
> semantics (e.g. gnucash register and guppi).  Even if you aren't using
> any external content, the XML/HTML is being used to control the GUI
> rendering.

That's mostly because the html layout engine is more refined, and
easier to deal with in a predictable way, than, e.g. the Motif
row-col widget, or the gtk canvas widget.   HTML with embedded
images & objects can be layed out far more neatly, and far more
succinctly, than the equivalent in hand-written gtk code.
Also, its 'run-time' adjustable ... don't need to recompile.

At least, that is why I promote its use.

> 3. Server-side "dumbing-down" of 2 to provide an acceptable interface
> for dumb clients.  For example the GUI widgets in Microsoft's
> .NET WebForms libraries can be:
> (a) downloaded as bytecode to run on .NET runtime, 

ahh, the unfullfilled promise of java applets ...

> user value changes
> are sent to the server using XML/SOAP callbacks

I like the idea of having html forms (buttons, text fields, etc.) 
be soap objects, hopefully obvious to anyone whose built any 
serious cgi-bin servers.

> SOAP/XML, 

is an infrastructure making it easier for developers to develop web
apps. And since it will be visual basic, or whatever, microsoft owns
more of the web.

Note that the lack of soap does not stop us (gnucash) from creeating
equivalent function 'by hand', which is essentially what I'm
proposing by stapling the gupppi object  (and a few others) to 
robs xml format (suitably tweaked).

All that soap *might* have given us is *maybe* a supporting
infrastructure to make some of this easier, *maybe*.  Except that I
think that passenger has already missed our boat.  I see no reason
to turn back and wait for soap to fully materialze before 
we build what I'm proposing.  In fact, using soap would only slow us
down, never mind hitch us to yet another unstable, rapidly evolving
technology.   As if we didn't have enough nasty dependencies.

> XML/HTTP/SOAP is used to unify distributed method calls and data transfer.
> Services are extensions of data transfer technologies -- providing
> content is one kind of service, but there are others (authentication,
> backup, synchronization, etc).

as others have pointed out, this risks being an order of magnitude
slower than corba. And it probably will be.  But then ... that may
not matter.  Maybe ..

--linas