Trial Balloon: A new DataStore Architecture?

[mike.perik@bankofamerica.com]

Aren't guaranteed to be delivered to the other side.

Mike

> -----Original Message-----
> From:	Derek Atkins [SMTP:warlord@MIT.EDU]
> Sent:	Tuesday, October 31, 2000 1:56 PM
> To:	Perik, Mike
> Cc:	jrb@redhat.com; rlb@cs.utexas.edu; gnucash-devel@gnucash.org
> Subject:	Re: Trial Balloon: A new DataStore Architecture?
> 
> Aren't guaranteed to be one-way, or aren't guaranteed to make
> it to the other side?
> 
> -derek
> 
> <mike.perik@bankofamerica.com> writes:
> 
> > CORBA oneway calls are not guaranteed.
> > 
> > Mike
> > 
> > > -----Original Message-----
> > > From:	Jonathan Blandford [SMTP:jrb@redhat.com]
> > > Sent:	Tuesday, October 31, 2000 2:28 PM
> > > To:	Derek Atkins
> > > Cc:	Rob Browning; gnucash-devel@gnucash.org
> > > Subject:	Re: Trial Balloon: A new DataStore Architecture?
> > > 
> > > 
> > > <delurk>
> > > 
> > > Hi Derek,
> > > 
> > > While I'm hardly a CORBA expert, I'd like to reply to some of these
> > > comments.
> > > 
> > > Derek Atkins <warlord@MIT.EDU> writes:
> > > 
> > > > Rob Browning <rlb@cs.utexas.edu> 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.
> > > 
> > > Thanks,
> > > -Jonathan
> > > 
> > > </delurk>
> > > 
> > > _______________________________________________
> > > gnucash-devel mailing list
> > > gnucash-devel@lists.gnumatic.com
> > > http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
>        warlord@MIT.EDU                        PGP key available
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel