Subject: Re: corba or sockets?
From: Erik Naggum <>
Date: 01 Nov 2000 02:32:55 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Jon S Anthony <>
| Again, if you're interested in getting into the protocol business,
| that's a different story.

  This seems to be your key argument, that there is a primary business
  and lots of ancillary concerns for which it is better to use the
  results of somebody else's primary business than dabble in it.  I do
  not agree with this for several reasons.  First, if you discover
  that you need better control over some ancillary concern, you may
  have to make it the primary business of some person or group in your
  company.  Second, if you find that you cannot afford to do it on
  your own, but need something different from the available offerings,
  you may cause somebody else to spawn a similar new primary business,
  such as a consortium.  Third, you may discover that as you go abaout
  your business, you gravitate towards certain concerns that are very
  different from what you set out to do, and your primary business may
  change to a previously ancillary concern, not the least because the
  only way to improve your previous primary business to do something
  else entirely.  All of these have happened to me, and I claim that
  if you're making any effort to be good at what you do, you will not
  be able to tell beforehand what you will do best in.

| Designing is only a fraction of the effort.

  I see that it is somehow important to you to exaggerate the costs of
  "rolling your own", but I'd like to know why.  It may be necessary
  to defend the choice of using CORBA, but I have _already_ stated in
  plain text and simple terms that if you can't do it better yourself,
  by all means, stick with what somebody else did even if that is not
  particularly good, so I hoped that we would have that condition
  behind us, but you keep carping on this cost of not doing it better.
  I fail to see the relevance in context.

  I'm effectively arguing that out-doing CORBA is not that hard, but
  having said

    CORBA is already badly designed, so if you are new to sockets and
    protocol design (which you will get yourself into), the likelihood
    that you, too, will design your protocol badly is so high that it
    is probably better to go with CORBA.

  the rather obvious (to me, anyway) ramification is that you should
  be good enough at what you do to out-do CORBA.

| You then need to implement it across several platforms and make it
| available for use in an effectively open ended set of languages (at
| the least C++ and Java).  Given what we are doing, I would guess it
| would have taken well over a person year or more of resources.  And
| for what?  To get something just as good?  Probably not even as good
| if you factor in such things as the IDL compilers, exceptions, and
| the like.

  I started out overhauling a system that spent 6 seconds from end
  system to end system at best, with more than 120 seconds worst case.
  It was the third generation of a system I built in 1989 that then
  guaranteed 2 seconds from end system to end system.  It was simply
  so incompetently done that it had to be rewritten.  I got it down to
  the old standards in the summer of 1998.  To move beyond that into
  the 500 ms guaranteed end system to end system transmission times,
  including more and more clients on the randomly performing Internet
  instead of dedicated lines with known characteristics, much higher
  bandwidth and even higher transmission needs, I had months and
  months of hard work cut out for me.

  This stuff is not for sale to random clients as a packaged product,
  and it won't be, either.  It is not in my employer's interest to
  sell the server side of my protocol, because that has become one of
  the main reasons we're ahead of the pack.  The protocol is intended
  to be open to the public and a tremendous amount of work has been
  put into ensuring that a client can be written in a short time, like
  a week for a reasonably competent programmer regardless of language,
  while the server has taken almost 18 months.

| Now, an order of magnitude better (depending on how that gain is
| distribted), that would be a different story, but the effort would
| go up dramatically and you are then basically in the distributed
| object protocol _business_ (or at least you _should_ be).

  I think you have a fairly naive view of the separation between the
  primary business and the ancillary concerns of an endeavor.  Our
  _primary_ business is delivering financial news to investors and
  brokers.  The protocol design became _my_ primary business when I
  found that we were destined to waste a lot of time if we stuck with
  off-the-shelf products, and I'm paid exceedingly well to develop,
  maintain, and promulgate this protocol.  This came to be because I
  have managers who saw the value of my work and listened to my
  concerns and honored my request to be free to work on this for as
  long as I wanted.  Now I can honestly say that whatever I take home
  from this project is miniscule compared to what it brings in.  This
  was not something that could have been realized if anyone had had
  the naive "primary business" view of what we intended to be good at.
  Nowhere in our business plans would you find mention of what I do
  for this company, because it isn't what we tell people about, and we
  don't make any money from my work, we make the money _with_ my work.

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