Re: [Fresco-devel] Re: ACE

Well, you've shown an ability to learn once; I'll try explaining
things one more time before deciding you're a troll.  At least the
information may be useful to someone else.

On Mon, Nov 25, 2002 at 11:30:45AM -0700, M. Evans wrote:
> 
> > You suggest we fork ACE and throw out all the parts we don't need, to
> > make it slim enough to be usable?  That's absurd.
> 
> What I'm suggesting that if IDL had ever lived up to its real promise,
> then it would enable ACE to expose to the external world just
> what the external world needs, and no more.  Internal dependencies would
> be irrelevant.  The fact that IDL cannot do this indicates that all the
> overhead of IDL is not worth much.
> 
> Or, that ACE's CORBA wrappers are incomplete, in which case it's better
> for you to contribute to ACE (factoring, interfacing) than to re-invent
> ACE on a smaller scale.

You clearly have no idea whatsoever of what CORBA, ACE, or both, are.

CORBA is a fairly complicated network protocol (and assorted
paraphernalia) for making distributed, multi-threaded method calls on
objects.  Method calls are fairly expensive, and a full-fledged ORB is
quite a complex thing to write.

ACE is a POSIX wrapper (on steroids); it's all about system level
functionality, providing interfaces to threads, networking,
pseudo-terminals, etc.  It's lower level than CORBA.  You can't use
CORBA to talk to ACE, there'd be no point; you'd need all the
resources ACE provides just to make the request for those resources.

Using ACE via CORBA would be like driving to the bus stop because you
don't have a car.  If you can use CORBA at all, then you already have
all the functionality you might want ACE to provide.

Your comment about ACE's internal dependencies is quite irrelevant to
the other things you mention in this paragraph.  The problem with ACE
is that it's huge, it generates huge libraries, it causes horribly
long compile times, and all that for no benefit (for what we'd be
using it for) compared to something simple like Prague, that doesn't
suffer from those problems.  Eliminating those problems would require
slimming ACE down, and slimming ACE down would be hard, because of the
internal dependencies.  I couldn't care less if an API I use exposes
more functionality than I need; that may be considered "bloat" by some
people, and it may tend to co-occur with other problems (like the ones
I described above), but by itself it's no problem.  You propose that
hiding ACE's interface behind something cleaner would (or should) make
it less bloated, but this is a non-sequitor, because I'm talking about
code size bloat, not interface bloat.

> > and something about IDL that makes no sense.  .NET is a wildly
> > different architecture from CORBA
> 
> Right, but it grew out of frustrations with the COM IDL scheme in
> Windows.

Possibly.

> > It's like comparing TCP/IP and the Pentium.
> 
> Oh bull.  They both try to accomplish language independence.  Though
> granted CORBA is a bigger monster than COM, that was a major goal,
> if not the only one.  Factoring software was another goal.

You make it sound like the quoted comment was comparing CORBA and COM,
not CORBA and .NET, which is quite a distortion of my original words.
I was talking about CORBA and .NET.

.NET is still a wildly different architecture from CORBA.  CORBA is
about letting different languages and runtimes talk to each other;
.NET is about putting everything into one runtime (and arguably[1],
into one language with some mild syntactic differences).  This is an
interesting thing, but it's not our thing; we're not interested quite
yet in throwing away the entire UNIX execution and process model.

[1] "arguably", meaning, I have heard this argument, some people agree
with it, I suspect others don't, and I'm not interested in discussing
the merits of the positions on this list.

> > And then you pull out this wildly irrelevant thing about Microsoft
> 
> I'll spell it out.  The relevance is that Microsoft, after years of work
> on IDL in Windows (COM, COM+, DCOM), decided that it wasn't making
> things happen in the real world -- for the same reasons you have
> discovered it can't make things happen with ACE.  Bloat, bloat, more
> bloat, tons of overhead, extra programming labor.  So it switched
> to .NET.  COM is still supported, but .NET is where Microsoft bet the
> bank.  So here we see a major OS software company essentially giving up
> on IDL approaches.

I really don't see how you're getting this.  I can sort of understand
your confusion about what ACE is as compared to CORBA (especially if
you're coming from a COM background), but I totally fail to see how
ACE's heavy use of templates, etc., could be "the same reasons"
COM/COM+/DCOM failed.  Unless MS's problem was that they were unwisely
using bad supporting software.

And .NET is a much bigger chunk of code than any CORBA implementation;
claiming that it's purpose was to _avoid_ bloat seems odd.

> CORBA is an IDL, and yes it can run across a network; so does DCOM.
> That's irrelevant.  What an IDL is supposed to do is expose
> well-factored interfaces to arbitrary IDL-capable languages.
> 
> The .NET approach scraps the IDL in favor of a common language
> runtime.  So there is no need to write IDL interfaces any more.
> Languages just plug and play because they are compiled to a common
> back-end.  No more IDL libraries!

A nice bit of advertisement for .NET, but I fail to see how it's
relevant, unless you're trying to somehow advocate that we switch to
.NET.  But as I said above, we're not ready to give up on the Unix
process model quite yet, and especially not in favor of an untested
environment designed by a monolithic company with (currently) no free
support.

> > It is, in fact,
> > _not_ easier to do that, than to just write the parts we need.  ACE is
> > huge, complicated, with a _lot_ of internal dependencies.
> 
> Oh, sorry, I thought IDLs were meant to hide internal dependencies.
> Guess not. :-)

As I said above, you can't hide implementation bloat at the API level.
It's still there, and still as much a problem as it ever was.

> So far all I've heard is that it's too hard to build, so you gave up
> and rolled your own code.

It's comments like this that make me think you're a troll.  Nobody
said this; you just made it up.

> Seems to me it would make more sense to
> contribute to the ACE project.  You lecture me about "forking," but
> this Prague thing is a prime example of exactly that -- forking.  Not
> in the strict technical sense, but in the broad sense.  There is
> no more serious fork than starting a whole new project to do the same
> thing.

We don't do "the same thing".  Prague solves some of the same general
problems as ACE, but with very different constraints.  This is like
saying the lynx developers should instead contribute to mozilla,
because both write code to do the same thing.

> This is how open source efforts defeat themselves, constantly reinventing
> wheels.  There are probably two dozen smaller Prague equivalents out
> there if ACE is not to your liking.  Argue all you want about ACE,
> there are many other libraries -- and now heaven help us, another one,
> Prague.

Oddly, it hasn't defeated us.  I'd want more empirical evidence,
preferably backed by some technical understanding.

> > Saying "it's always easier to strip things down" is simply not true in
> > the real world, and makes me wonder how much time you've spent doing
> > actual engineering.
> 
> Oh come on.  I'm a professional making six figures.  I know my code
> and how to manage my time.  I've seen the not-invented-here syndrome
> before.
>
> Besides, my goodness, I can't believe what I'm hearing -- people
> interested in slim libraries who depend upon CORBA, the most notorious
> bloatware in the known universe.

If this responded to the point, it might not be trollbait.

> IDLs are supposed to hide internal dependencies, let you use what
> interfaces you want, etc.  Even if ACE lacks required interfaces, it
> would be more sensible for Fresco to contribute them than re-invent
> pieces of ACE.  Or to find another open-source library more to your
> liking.  The problems solved by Prague have been solved before, many
> many times.
>
> > However, because TAO uses ACE, it generates extremely bloated
> > libraries, so huge that Stefan never even tried using them.  This
> > could be considered a bug in TAO.
> 
> So the obvious solution is to work on TAO not ex nihilo creation of
> ACE-lite.

The way to make TAO lighter is to create ACE-lite.  Of two identical
things, you prefer one over the other?

> > ACE is not a CORBA system.  I don't see how ACE being overkill as a
> > POSIX wrapper makes the "whole CORBA idea" untenable.
> 
> Assuming ACE were completely wrapped with CORBA interfaces,
> I don't see how a system wrapped in CORBA could be considered overkill
> unless CORBA itself is a failure.

> Besides, I think the whole overkill notion belies a failure on your
> part to appreciate the potential for growth in Fresco.  You might find
> ten years from now that Prague has become ACE in all but name.

Possibly.  But that would require some absurd feature creep on the
part of Fresco; ACE is as research system to investigate pretty ways
to make objects solve nasty high performance communications problems.
Fresco doesn't have any nasty high performance communications
problems (well, except for making CORBA fast, but that's not our job,
it's the ORB's).

Unless, of course, you wanted a window server and ATM router (with
realtime guarantees!) all in one :-).

> Actually I'm a very nice person.  Just very opinionated. :-)

Glad to hear it.  I'd just request that in the future, you start with
facts, and _then_ move on to opinions?

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender

This email may be read aloud.