Trial Balloon: A new DataStore Architecture?
Tue, 31 Oct 2000 13:24:54 -0600
CORBA oneway calls are not guaranteed.
> -----Original Message-----
> From: Jonathan Blandford [SMTP:firstname.lastname@example.org]
> Sent: Tuesday, October 31, 2000 2:28 PM
> To: Derek Atkins
> Cc: Rob Browning; email@example.com
> Subject: Re: Trial Balloon: A new DataStore Architecture?
> Hi Derek,
> While I'm hardly a CORBA expert, I'd like to reply to some of these
> Derek Atkins <warlord@MIT.EDU> writes:
> > Rob Browning <firstname.lastname@example.org> writes:
> > > On the data communication side, there's also CORBA to consider.
> > I personally dislike CORBA. My reasoning is two-fold:
> > 1) Synchronous RPC is BAD (in many cases).
> > 2) CORBA tries to push protocol design onto programmers.. But
> > good programmers are not necessarily good protocol
> > designers (and vice-versa).
> > A real-world example of this: M$ Outlook requires 84 RPC calls to open
> > a mail folder. If your mail server is a few hundred miles away, it
> > can take, literally, several SECONDS in order to open it. Why? The
> > program has to pause and wait for each RPC to finish before it can
> > make the next request, and the transmission delay time can be
> > relatively large in a widely-distributed network.
> 84 RPC calls? That's pretty heavy, regardless of the protocol or
> mechanism. But that aside, CORBA has the oneway directive that lets you
> send asynchronous requests.
> > A real protcol would let you send multiple requests consecutively and
> > let the responses come asynchronously. Unfortunately CORBA does not
> > let you do this.
> Yes it can. You can send multiple oneway requests, and let the remote
> object send oneway replies back.
> > 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.
> > Frankly, I don't think that designing a real protocol would be
> > difficult. I also don't think it needs to happen right away. I think
> > we can architect and implement the data model using local storage
> > before designing the network protocol. At least a set of access
> > requirements should come first.
> gnucash-devel mailing list