On 28-Dec-2000, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Tyson Dowd <[EMAIL PROTECTED]> writes:
>
> > 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.
>
> <FLAME>
> What the hell are you talking about? Are you just pulling this SH*T
> out of your ass or something???? Do you even know what SunRPC is?
> Have you even looked at CORBA? Or are you just trolling, throwing out
> complete nonesense just to see what kind of reaction you can get from
> people?
> </FLAME>
Derek, please go back and check the thread of this email.
Linas was saying you can do gnucash-as-an-ASP style stuff using some
sort of roll your own solution using CGI. If you are going to do that,
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.
I'm certainly not advocating using SOAP instead of CORBA in all situations.
However, the ASP scenario that Linas was talking about sounds like the
kind of situation where users may need to go over the open internet.
I have a published paper on a CORBA language binding I implemented, so
to answer your question -- yes, I have heard of CORBA.
> > 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.
>
> This is a huge problem. And you can't stop tracking changes unless
> you incorporate the whole SOAP subsystem within GnuCash. 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.
- socket library for doing HTTP (actually only some of it
amount needs to be implemented).
- code to decide which method to call given a SOAP message. Can
be as simple or as complex as you like.
Note that the first two ideas have to be written anyway if you are doing
what Linas proposed (use specially marked up HTML to render Gnucash
visuals with engine running as a cgi-bin).
CORBA is a significantly more complex system. You need to write the
IDL, it gets converted to a C representation according to the language
binding, then you have to write code that converts your data structures
to and from this representation. You need to install an ORB at client
and server end. You need to configure your setup so you can find the
name server via an IOR, and you need open ports at both ends. The
stubs and skeleton implementation of the client/server is usually linked
in at both ends, requiring libraries and other bits and pieces.
The SOAP stuff is simpler because we took some shortcuts -- we already had
an XML data representation for Gnucash data, so we used it -- strictly
speaking you should use the representation given by the XML schemas
stuff in the spec, but it doesn't really matter too much. We don't
need to implement any part of SOAP that we aren't using, so 90% of the
spec is unnecessary. So I really shouldn't call it SOAP. Perhaps
SOAP-like is a better term.
> > Hmmm... CORBA over IIOP is practically the same.
> > I doubt there will be a measurable diffence.
>
> I haven't done any CORBA/IIOP measurements personally, however you
> only need a single connection between any two ORBs and messages are, I
> believe, multiplexed across. You also get the difference in that
> CORBA can be used from C whereas (currently) SOAP cannot. Unless, of
> course, you roll your own. ;)
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.
> > 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?
>
> 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. (I never said firewalls are evil, just that
> firewalls should never be used ALONE. :) You want to be able to
> specifically allow or disallow connections of this manner. And all
> firewalls are configurable, but not all firewalls can actually look
> into the protocol and tell the difference between SOAP and Porn.
In some scenarios this is true, but I thought we were discussing the one
Linas pointed out in his email that started the topic "client-server":
Linas: -- We've side-stepped the sql transport issue, sort-of. All
Linas: data between gnucash-the-web-browser and
Linas: gnc-the-apache-server is in the form of this oddly marked-up
Linas: html with embedded, uuencoded gnc-xml. On the server side,
Linas: we have to write some cgi-bins that yank data from any old
Linas: sql db, and convert it into gnc-xml. (personally, I recommed
Linas: using gnc-engine to implement those cgi-bins).
So we are already in HTTP land, logged in over the open internet.
All I'm advocating is that it might be a nice idea to use SOAP for some
of the message passing in this environment. It seems absolutely
bizarre to take a system that is already running the gnc-engine as
a cgi-bin, communicating in mostly XML, and then whack CORBA or regular
RPC on the side of it.
So it sounds very much to me like we are talking about completely different
client-server ideas, with very different requirements. I have
absolutely no problems with using CORBA in other environments -- I think
it's fine. But I don't think CORBA with an IIOP transport will cut the
mustard in an open-internet environment.
--
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
