On 19-Apr-1999, Rob Browning <[EMAIL PROTECTED]> wrote:
>
> Daniel R Risacher <[EMAIL PROTECTED]> writes:
>
> > At the risk of a heated discussion (aka flames), did you consider
> > CORBA as an alternative?
>
> Tyson and Daniel,
>
> CORBA is probably worth considering, but the biggest problem I have
> with it right now is that I know nearly nothing about it, and I want
> to get something working right RSN.
That's correct, that's definitely the biggest problem.
>
> Actually, if I go with the proposal I made, there shouldn't be any
> substantial wasted work since it should be trivial to convert the
> .scrx files to CORBA specs rather than SWIG or g-wrap specs. That's
> one nice thing about specifying your exported API in a very easy to
> parse (if you know you have a scheme interpreter lying around), and
> implementation independent, manner.
You are right, it would be pretty easy to do this, and I believe it
is a good way to go forward. But I think it's a good idea to try
to aim towards CORBA (or something like it) in the long term, and
keep that in mind when designing interfaces.
> Also, not knowing much about CORBA, I do have a few impressions I've
> picked up (which may or may not be accurate) from observing
> discussions about CORBA, and from a couple of visiting cluefuls that
> lectured here. Feel free to shoot these items down or ignore them,
> but I thought I'd make clear what my impressions actually were:
>
> Again, these are repeating what I've heard, not what I know:
>
> * CORBA has serious security problems that can't be easily fixed.
Like Unix and C and many other practical and useful systems, CORBA
doesn't set out to solve all problems at once. It provides good
support for distributed services and inter-language operation.
CORBA doesn't itself preclude you from using already known
security techniques inside the communications protocol. It just
doesn't add magical security to an insecure setup.
> * CORBA would require a bunch of additional work on top of the
> .scrx files.
Not really. You need to write an interface turning gnucash data types
into their CORBA equivalents, but I suspect you will have to do very
similar things for any non-trivial communication anyway.
>
> * CORBA is fairly ill conceived for many tasks. (This was from a
> researcher visiting who had a really impressive *working*
> distributed computation/communication architecture that handled
> all kinds of things like redundancy, server restarts (where the
> servers pick up where the last one left off transparently (as far
> as the rest of the net is concerned)) local caching,
> etc. automatically. He tended to thing that CORBA poorly thought
> out and wasn't nearly flexible enough for many tasks. It forced
> you into one model which often wasn't appropriate for many
> distributed tasks. (Though this isn't really relevant in our
> case. We just need it for straightforward local stuff right now).
I'm not well versed enough to defend CORBA in any way. It is an
industry standard. It does a number of things well. I'm sure it has
plenty of drawbacks not encountered in more experimental systems, but
the point is CORBA is available and deployed.
> * CORBA would add another dependency (probably on orbit which isn't
> too bad since GNOME already requires it), but how stable is orbit?
This is a problem at the moment. Although orbit has gained a lot of
ground lately.
>
> All that said, I have no real idea whether or not CORBA would be the
> right thing. However, I am tempted to just proceed with SWIG and see
> if it works. Much of that effort would also apply toward CORBA, and
> we could always switch later.
I believe this is a fine course of action, as long as you consider that
we may want to get away from it in future, and plan accordingly.
The plan you outlined sounds like a fine idea.
If I had more time I'd love to help and do the CORBA stuff (and an SQL
backend), but I've got a 3 week trip to the USA coming up next week.
--
The quantum sort:
while (!sorted) { do_nothing(); }
Tyson Dowd <[EMAIL PROTECTED]> http://tyse.net/
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
