Trial Balloon: A new DataStore Architecture?

Jonathan Blandford jrb@redhat.com
31 Oct 2000 16:31:17 -0500


Derek Atkins <warlord@MIT.EDU> writes:

> > Yes it can.  You can send multiple oneway requests, and let the remote
> > object send oneway replies back.
> 
> ... at this point what added benefit are you getting from CORBA?  To
> me, at this point you are still defining a protocol, and using CORBA
> for object transmission.  In that case, why not use something simpler,
> like XDR?  That's been greatly tested and has been around much longer
> than CORBA.  It's also a much smaller piece of code, which implies
> less compexity.

Less code to write.  More code share amongst other apps on your desktop
(ie. those using GNOME).  If gnucash ever decides to use Bonobo, it'll
need to be using CORBA anyway.  The thing about protocols (especially
those involving applications) is that they tend to grow.  CORBA at least
is very expressive.

> > > Another potential problem is the security of CORBA.. Namely, there is
> > > none.:) I would personally insist on data encryption and strong
> > > (kerberos-level or greater) user authentication.
> > 
> > I'd argue that writing my own protocol is less secure, as there's more
> > complexity in the code, more room for error, it's one more dependency on
> > the system etc. etc.  At least with ORBit, there are a number of other
> > people using it.  Additionally, ORBit 2.0 has support for SSL built in.
> > Authentication is a separate kettle of fish, and needs addressing
> > independent of the protocol used.
> 
> I suppose the complexity depends on the protocol in question.  However
> I do believe that it is possible to make a simple protocol which is
> much less complex than CORBA.  Don't forget that you have to consider
> all the parts of CORBA when you consider the complexity of the result.
> I don't think you can only talking about your IDL files and the
> supporting routines.
> 
> SSL is nice, but IMHO insufficient for our purposes.  At least the
> certificate model in SSL is inappropriate.  I would also disagree that
> Authentication is a "separate kettle of fish."  I think it is just as
> important as encryption, and the protocol needs to be security-aware.
> If you make a protocol without considering security as a part of the
> protocol, you will find that adding security after-the-fact is
> challenging or impossible, depending on your security considerations.
> I say this from personal experience (by day I'm a Network Security and
> encryption researcher, as well as protocol architect.  Ever heard of
> PGP?  I wrote it :-)

I know who you are, Derek -- you used to "live" in my dorm... (-:

I'm not going to go about posing as a security expert, and am willing to
defer to you on this.  My point was simply that authentication is a
problem that needs solving independent of whether or not you use CORBA
as your transport or not.  My gut instinct is simply that whichever
mechanism gnucash uses -- homegrown or otherwise -- adding
authentication to is is going to be reasonably similar.

> I'm certainly open to the concept of using CORBA, but I don't think
> that we need all the services that CORBA provides.  Perhaps as we
> flush out the requirements I might be proved wrong.

Presumably we don't need to use the entire CORBA standard.  (-:  But as I
have not volunteered any time or energy to this project beyond those of
a user, I won't argue this point too strongly.

Thanks,
-Jonathan