[omniORB] Shopping for CORBA ORB and reencounter with The Mystery
Rob Cecil
rceci@master.adams.com
Mon, 22 Nov 1999 11:15:23 -0500
--------------B51FE1CA4D17654CB8EDE5A3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I believe omniORB and TAO have quite different goals. The omniORB folks at AT&T basically
needed specific set of Corba functionality, for their other projects. It turns out that
their orb is highly useful in other contexts. TAO started with different goals, realtime
being just one. That is why combined effort would probably not happen.
Rob
Zach Buckner wrote:
> The shopping experience:
>
> My requirements were:
> Free, high performance, reliable, C++ bindings. It had to be easy to
> use and properly packaged (didn't want to spend time fooling with
> Makefiles)
>
> The contestants:
> Mico looked like a hack, had a poor track record, and didn't include
> binaries...
>
> TAO looked most promising, but didn't include binaries... didn't
> compile first few attempts.
>
> OmniORB looked good, appeared to have a solid track record, and
> included binaries for WinNT and Linux. OmniORB was the choice... one
> month ago.
>
> The Mystery
>
> I've spent the afternoon reading info from TAO web site (patterns
> within TAO, etc.) and - at least from the inside - TAO looks
> fantastic. I began to wonder whether OmniORB was, truly, the best
> candidate. This, in turn, led to 'why these two great projects don't
> work together?' OmniORB and TAO appear to have the same goals
> (TAO may be geared toward real-time / high performance, but due to
> their 'dynamic configuration'... it seems that one could shape it to
> any conceivable behavior.) Wouldn't the combo be > the sum of its
> parts?
>
> Are the problems related to pride (developers want to continue to
> nurse their own puppy), legal hassle (differences in licenses),
> development hassle (face-to-face development via teams / academic
> circles is still better than internet-based development), corporate /
> political (the corporate / academic ties make the projects inflexible
> in this respect), or the competitive spirit? None of these seem
> insurmountable, and none seem to outweigh the advantages of having a
> combined effort. I know that I would be more likely to contribute
> to ORB development (which involves a lot of learning overhead for mere
> ORB users like me) if I felt that these projects weren't so volatile.
>
> Can anyone provide an answer? I assume this is a FAQ in free software
> discussion groups (many free/OS development efforts seem splintered).
>
> -Zach
--
| Rob Cecil | Senior Development Engineer |
| rceci@adams.com | Product Development |
| (734) 913-9351 | Mechanical Dynamics, Inc. (www.adams.com) |
--------------------------------------------------------------------
Modern Quantum Physics has found that the universe is composed of
25% protons, 15% electrons, 15% neutrons, and 45% morons.
--------------B51FE1CA4D17654CB8EDE5A3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I believe omniORB and TAO have quite different goals. The omniORB
folks at AT&T basically needed specific set of Corba functionality,
for their other projects. It turns out that their orb is highly useful
in other contexts. TAO started with different goals, realtime being
just one. That is why combined effort would probably not happen.
<p>Rob
<br>
<p>Zach Buckner wrote:
<blockquote TYPE=CITE>The shopping experience:
<p> My requirements were:
<br> Free, high performance, reliable, C++ bindings.
It had to be easy to
<br> use and properly packaged (didn't want to spend time fooling
with
<br> Makefiles)
<p> The contestants:
<br> Mico looked like a hack, had a poor track record, and
didn't include
<br> binaries...
<p> TAO looked most promising, but didn't include binaries...
didn't
<br> compile first few attempts.
<p> OmniORB looked good, appeared to have a solid track record,
and
<br> included binaries for WinNT and Linux. OmniORB was
the choice... one
<br> month ago.
<p>The Mystery
<p> I've spent the afternoon reading info from TAO web site
(patterns
<br> within TAO, etc.) and - at least from the inside - TAO
looks
<br> fantastic. I began to wonder whether OmniORB was,
truly, the best
<br> candidate. This, in turn, led to 'why these
two great projects don't
<br> work together?' OmniORB and TAO appear to have the
same goals
<br> (TAO may be geared toward real-time / high performance,
but due to
<br> their 'dynamic configuration'... it seems that one could
shape it to
<br> any conceivable behavior.) Wouldn't the combo be
> the sum of its
<br> parts?
<p> Are the problems related to pride (developers want to continue
to
<br> nurse their own puppy), legal hassle (differences in licenses),
<br> development hassle (face-to-face development via teams
/ academic
<br> circles is still better than internet-based development),
corporate /
<br> political (the corporate / academic ties make the projects
inflexible
<br> in this respect), or the competitive spirit? None
of these seem
<br> insurmountable, and none seem to outweigh the advantages
of having a
<br> combined effort. I know that I would
be more likely to contribute
<br> to ORB development (which involves a lot of learning overhead
for mere
<br> ORB users like me) if I felt that these projects weren't
so volatile.
<p> Can anyone provide an answer? I assume this is a
FAQ in free software
<br> discussion groups (many free/OS development efforts seem
splintered).
<p>-Zach</blockquote>
<pre>--
| Rob Cecil | Senior Development Engineer |
| rceci@adams.com | Product Development |
| (734) 913-9351 | Mechanical Dynamics, Inc. (www.adams.com) |
--------------------------------------------------------------------
Modern Quantum Physics has found that the universe is composed of
25% protons, 15% electrons, 15% neutrons, and 45% morons.</pre>
</html>
--------------B51FE1CA4D17654CB8EDE5A3--