On 22-Dec-2000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 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.
AFAIK there's no C binding out there. But SOAP isn't as hooked on
bindings as CORBA is. If you can open a socket, send out the right
headers, and spit out some XML, you can do 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.
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.
> > 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.
Infrastructure implies some sort of overarching, bulky system. I would
say instead that SOAP is a cookbook for doing RPC using HTTP and XML.
The infrastructure you require is a socket library, and the ability to
parse and generate "POST" HTTP headers.
If you want to write *whole language* bindings or need the equivalent of
IDL, then you start to develop infrastructure. Otherwise you're just
writing a network protocol.
> 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).
No. But if you are going to add RPC to this system, then you might as
well adopt the SOAP standards, since it's a no more work than rolling
your own.
> 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.
As opposed to the roll-your own technology, which is stable and static,
I assume ;-)
There is definitely the problem that SOAP is a bit of a moving target,
and that support for it is immature. But that can't really cause any
problems when your alternative is to roll-your own! You can always stop
tracking the changes and start making your own modifications if you
want.
But you are certainly right in that there is no point waiting for it to
stabilize. The only benefit you get from sticking to the standard is
that you get interoperability with other people who stuck to the
standard (language bindings are the big winners here).
>
> > 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 ..
Hmmm... CORBA over IIOP is practically the same.
I doubt there will be a measurable diffence.
If the applications are in the same address space it will be heaps
slower. But otherwise, I can't see any huge efficiency differences in
the network protocols, except that IIOP will be blocked by most
firewalls, where as SOAP over HTTP will not. Is there something I'm
missing?
--
Tyson Dowd #
# Surreal humour isn't everyone's cup of fur.
[EMAIL PROTECTED] #
http://www.cs.mu.oz.au/~trd #
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
