client-server

[linas@linas.org]

> > <FLAME>

Can we not flame?
There's a second level of issues tat we aven't gotten into yet, and
these can't be discussed in a hostile enviroment.


> Linas was saying you can do gnucash-as-an-ASP style stuff using some
> sort of roll your own solution using CGI.  

What I was saying is that given what we've already rolled (an XML
file format, and html-embeddable guppi objects) we've already
implemented 98% of the data transport and display infrastructure.
Furthermore, its such that useful stuff can be done with at most
minor modifications of the client.

Go to www.gnucash.org and click on 'test' link thats hidden on the bottom
of the page.

> then I'm saying SOAP would be a better solution than some arbitrary XML
> over HTTP solution, at least for the kind of message passing stuff that
> such a system is likely to do.

What I was proposing was a system that could do many interesting things,
but because it lacked 'events', is limited in scope.

Id like to hear someone give a technical overview of how SOAP handles
events.

> > This is a huge problem.  And you can't stop tracking changes unless
> > you incorporate the whole SOAP subsystem within GnuCash.  Ewwww..

ewwww!

> The whole SOAP subsystem for C:
> 	- code to parse and generate XML.  Already in gnucash code base
> 	  for most of the complicated data types that gnucash uses.

libxml

> 	- socket library for doing HTTP (actually only some of it
> 	  amount needs to be implemented).

libghttp

>       - code to decide which method to call given a SOAP message.  Can
> 	  be as simple or as complex as you like.

uhh, I thought this is exactly what a generic implementation of SOAP
would provide ?? 

> Note that the first two ideas have to be written anyway 

have already been written ...

> what Linas proposed (use specially marked up HTML to render Gnucash
> visuals 

has already been written. Its the underlyig basis for how gnucash
will display graphs & reports.  The bad news is that the more
complex, more generic reporting infrastructure is not in place.
However, that has nothing to do with soap/http/htm/xml.

> SOAP can be used from C, you just have to do a bit more work yourself.
> The difficult part is marshalling your data to XML.  

I assume tat a generic SOAP implementation would provide marshalling
and unmarshallig, right?

> > > the network protocols, except that IIOP will be blocked by most
> > > firewalls, where as SOAP over HTTP will not.  
> > 
> > Being able to differentiate between GnuCash transactions and regular
> > HTTP is actually a GOOD THING!  You WANT to be able to firewall off
> > your financial system.  

Apache doesn't have to run on port 80. It can run on any port.
If you want to firewall your internal apache server, then pick a 
port number that your sysadmin promises to block. e.g. 1080 or 
8080 or 4443 or something.  

Besides, NAT-based firewalls don't allow external traffic to comin
anyway, except as a return on an already-open socket.


> then whack CORBA or regular RPC on the side of it.

Maybe we need a plugin architecture? 

My XML proposal overcomes a variety of administrative and practical
hurdles in a simple, standard, minmalist, even 'low-tech' kind of way.  
You don't need to be a rocket scientist to implement, install, configure,
manage it.

On the other hand, an RPC or corba backend migt be able to do some
interesting, powerful things.   I don't think I want to discourage
it, other than to say that it should be done so that gnucash doesn't
become even harder to build.



--linas