Subject: Re: corba or sockets?
From: Erik Naggum <erik@naggum.net>
Date: 31 Oct 2000 00:56:07 +0000
Newsgroups: comp.lang.lisp
Message-ID: <3181942567437276@naggum.net>

* Jon S Anthony <jsa@synquiry.com>
| The real question should be whether you believe your new protocol adds
| real value to what it is you are producing.  If you are in the
| protocol business this is obvious.  If you are in something else
| entirely and only need to make use of protocols, it is highly unlikely
| that the time spent on inventing yet another one will be of any real
| value for your project/product.

  I disagree with this assessment.  It is the same argument that can
  be made for something overly complex and badly implemented, like
  SGML,  It has also been touted as solving problems that people would
  not be able to solve cheaper by themselves.  That was just plain
  false.  Similar problems crop up with other committee products that
  have tried to solve overly broad and thus non-existing problems
  instead of trying to solve real problems of real complexity.

  How much effort does it take a good system designer to come up with
  something better than XML for any _particular_ purpose?  If he
  grasps the good and useful qualities of SGML, a simplified syntax,
  slightly general tools, etc, can be written in a fairly short amount
  of time, and it costs less to develop, maintain, and use than a
  full-fledged SGML system does, because, importantly, SGML's full
  generality has surpassed the point where additional features bring
  nothing but more costs than benefits to the equation..  A particular
  markup language (or something similar) is also easier to learn for
  someone who has _not_ spent much too much time studying the original
  -- like one one who is only moderately familiar with the original.

| CORBA is _not_ anything like the best distributed object protocol
| that one could define - probably a legacy of the C++ mentality of
| most of the original vendors involved.  However, it _does_ work
| rather well for many scenarios - most any that someone not in the
| protocol tool business would care about.

  Precisely, but having designed a few protocols that have been in
  wide use for over a decade each, just how much effort do you think
  it is to design new ones?  The reason protocol design is hard is
  that people are told not to do it, and thus do not investigate the
  issues involved.  This also leads to incredibly bad protocols in
  use, because the users are told they are too hard to understand.

| This has not been true since at least CORBA 2.0.

  I'm "happy" to hear that.

| The nice thing about using CORBA to do this is that it at least
| eliminates all the marshalling and unmarshalling of data items
| (primitive and structured) in a platform independent way.

  You know, this is _not_ a hard problem.  It is a hard problem in C++
  and the like, but that is because those languages have lost every
  trace of the information the compiler had when building the code.
  That design mistakes has cost the world _billions_ of dollars.  If
  you don't make that design mistake, you don't have to worry.  I
  know, this sounds "too good to be true", but the inability of any
  small C++ program to read C++ source code and do useful things with
  it is the reason for all these weird data-oriented languages.

| Unless your business is really line protocols or something similar,
| rolling your own here with sockets is just a distracting waste of
| resources.

  Well, I have tried both approaches.  Have you?

| Only if you don't make use of threads in making the calls in the
| first place.  If each call is a thread, the "waiting for the
| synchronous reply" is irrelevant.  Most ORBs are multithreaded and
| can easily handle this.

  Right.  Not my experience.  Of course, everything gets better in the
  mythical "future", so do stay with CORBA if you have other things to
  do while waiting for the synchronous request for more features sees
  a response from the CORBA people.  (Sorry, a tad rambling here.)

| Well we have done it at 2000 miles and the results were basically
| "instantaneous" (well under a second).  Using straight X was death.
| Using HTTP was (of course) worse than death.

  How long time do you think you would have spent designing a protocol
  that would have been just as good?

#:Erik
-- 
  Does anyone remember where I parked Air Force One?
                                   -- George W. Bush