Re: [Fresco-devel] [ReFresco 01] Why CORBA is inappropriate for Fresco

As usual, the post is unfinished and I also wanted to think over my 
position again, but the meeting is coming up, so just posting as-is.

Too bad I'll probably be unable to attend the meeting, because I have 
another meeting at the same time :-(. I really wanted to participate.

Well, maybe you can at least take this into consideration.

Friendly greetings,

Ben

Nathaniel Smith wrote:

>No, bloat is not a priori a bad thing; we do use most of what CORBA offers.  (On the other hand, I think unnecessary complexity _is_ a priori a bad thing, and that we can get by with rather less than what CORBA offers.
>[...]
>Ugly generally
>  - Designed by committee
>  - Everything is possible in theory
>  - ...which obscures that in practice, so much is impossible or
>    extraordinarily difficult.
>
>Complexity is the mind-killer.
>
If you mean that as a serious argument, can you found that more? Bloat 
generally means (to my understanding) that a software is either (a) in 
an unnecessarily bad shape (overly complex) or (b) totally unsuited for 
the task, because it supports features not needed for your project, but 
these features come at a significant cost.

If you mean (a): Which concrete attributes make CORBA badly designed? 
Why do they hurt? Why do you think did they happen? Why won't an 
alternative suffer from that problem or its solution?
If you mean (b): As I said, you can often see that custom-breed 
solutions eventually approach the complexity of the standard solution 
they originally avoided/replaced, but due to the smaller scale were not 
as well thought-out and in the end inferiour to the original solution. 
Given the relatively large number of CORBA features Fresco does use or 
could use well, I'd see Fresco going down exactly that path. Which 
concrete features are superfluous? Do they hurt? Are you sure that 
Fresco will never need them?

While you make the list, please also make a list of the CORBA features 
and services we *do* use or could use well in the future, and what it 
would cost to specify and implement them for the alternative IPC 
mechanism, for all languages/platforms and environments. Also compare 
the cost of programmer education and user installation, for the cases 
that CORBA is established already and that Fresco is the only programm 
which does and will ever use CORBA. So, which alternative solution has 
to be and can be achieved realistically, how would that look like after 
10 years of broad use, and how does *that* compare to CORBA from a 
programmer and user standpoint?

>Fresco is just hard to work on, confusing, and with a huge learning curve.
>
IMHO, if you roll your own protocol, you make the learning curve only 
harder overall. CORBA is a *generic* *standard*, either people know it 
already and feel home immediately or they learn something which they can 
use very well in their own applications (see below).

When I got into Fresco, I didn't know CORBA, and it was indeed the 
hardest part about using Fresco. There were quite frustrating moments, 
IIRC. However, I had a feeling that I learn something useful, which I 
can use in other, unrelated projects, too (which I now do). When 
confronted with a custom component or communication or string library in 
other projects, I am immediately put off, because I know the time I 
invest into learning it will be useful for that project only at best and 
wasted at worst (if I don't use that project further). (It is very rare 
that I find some *new* or *interesting* ideas in these custom solutions, 
which would make the learning worth it.) Also, these custom solution 
often change over time, requiring me to constantly re-learn other 
people's arbitary and short-sighted decisions.

CORBA can be (for what it does) very easy to use for the programmer, 
given the right language mapping. I'd say the standard C++ mapping isn't 
one of them (although there are alternative mappings for C++), but the 
Java one is.

Consider that if Fresco does succeed and gets used and deployed widely, 
the cost of programmer education, client development and user 
installation is far higher than that of developing the server. But the 
Fresco project still has to shoulder the development of the server, and 
now possibly including the development of the IPC mechanism together 
with its services.


<rant>
My experience with the Mozilla project was a nightmare. They did that, 
on almost all levels: They have their own libc wrapper, string library, 
component library, network library, widget toolkit. All in the sake of 
"cross-platform". Reality is that many of these solutions are poor 
reflections of other work, usually designed ad-hoc, implemented quick 
and dirty, and constantly changing the implementation and APIs. The 
result is that a ton of time is wasted on not only implementing these 
solutions, but much more time fighting with them, by discovering bugs 
(ah, so the XUL <deck> doesn't actually work, at least not for the 
elements I used? Nice to notice after a day bug-hunting in your own 
code) and adjusting to changing APIs (Mozilla extensions break with 
almost every Mozilla release. We had *3* different string libraries and 
APIs during the time I am involved with the Mozilla project, not 
counting char*s, which were also en vogue for a long time, and I can't 
count the the times when the mandatory "best practice" about string API 
use changed).
Maybe I am a burned child, but I now run away when I see somebody 
re-implementing a custom solution, while a generic, standard and 
time-proven solution already exists, even if it may not seem perfectly 
suited. This is especially true for strings, component/communication and 
widgets.

Even apart from these general reservations, which IMHO are significant, 
what about work load? You say there are not enough suitable CORBA ORBs, 
but there at least *some*. If you roll your own protocol, you have to 
implement them *all* by yourself. Who's going to write the Java 
interface, the Perl, Smalltalk etc. one?
Many of the custom solutions, which start off small and look doable, 
grow to extended requirements over time, often eventually replicating 
what the pre-existing, "bloated" solution did years ago. Not just is 
that a lot of work, but usually ends up being worse than the generic 
solutions, because it's a patch-work design- and implementation-wise and 
because it's only intended for one project, so not as much time 
investment is justified. And during that "growing up", the APIs still 
often change somewhat, being part of the cause of the problems mentioned 
above. If you want to do things properly from the start, you have to 
start thinking and discussing about them, which also takes lots of time.

To avoid the NIH (not invented here) syndrome is exactly what I liked 
about Fresco.
</rant>

>- Very few real implementations
>    Java: JacORB
>    C++: OmniORB, possibly TAO and MICO
>    Python: OmniORBpy
>    C: none
>    Perl: none
>    Ruby: none
>    TCL: none
>    Smalltalk: none
>    Lisp/Scheme: none
>
This is not true.

First, Sun Java 1.4 Standard Edition and following (which includes the 
Sun CORBA ORB) works *out of the box* with Fresco, if you just use my 
trivial meta.idl. I recently confirmed that. Java also supports RMI via 
CORBA IIOP, but I haven't tried that.

Second, there is a *ton* of ORBs. There are at least 5 or so *free 
software* ORB implementations in *Java* alone, and a bucketload of 
commerical Java ones from IBM/WebSphere, BEA WebLogic, Borland etc., 
which are standard equipment in business application development.

Didn't you write a little chat app for Berlin in Perl yourself a few 
years ago?

Plus other ORBs in other languages, but didn't check those out myself, 
at least not recently.

Your list only holds true for ORBs which work out of the box with 
Fresco's IDL, /without/ my meta.idl, and that's to the most part because 
Fresco's IDLs *deliberately* employs obscure features of CORBA IDL, e.g. 
the interface declaration without later definition. When asked to lift 
this, Stefan cited the CORBA standard and the working omniORB 
implementation, which is a valid stance, but doesn't change the fact 
that Fresco is not cooperating with most ORBs, although it *could* 
without much or any sacrifice to the actual APIs. So, if the lack of 
ORBs is a reason to drop CORBA, then I'd first fine-tune the IDL to 
better cooperate with ORBs, even if it means to organize the IDL files a 
bit differently.

>JacORB and MICO got the little bit better that was
>    necessary to support Fresco.  Or at least I think MICO did, I'm
>    not even sure.
>
FYI, JacORB does actually work with Fresco, I had it running here. So 
does Sun's ORB shipping with Java.

>  - Lots of people argue that the C++ mapping sucks, and the
>    conventional answer is that this is a client-side issue, and
>    should be fixed without changing the rest of CORBA.  Which is a
>    fine answer, but such arguers are admitting that the C++ client
>    mapping is flawed; and if you believe that, then C++ doesn't have
>    any good ORBs either, leaving _only_ Java and Python that are well
>    supported.
>
All true.
However, IMHO, while the C++ mapping does suck, it's IMHO not much worse 
than what C++ programmers are used to. For example, I don't like the 
manual memory management, but that's standard with how C++ is commonly used.

(Did somebody else give that "conventional answer"? I thought it was 
just me. I was excited when I stumbled across that idea long ago at 
<http://www.rostock.igd.fhg.de/fhg_igd/abteilungen/a1/veroeff/veroeff97/ecoop_paper.html> 
and <http://www.ispras.ru/~dkv/superstr.html>.)

>Do you want to write fully compliant ORBs for every language worth supporting?
>
You don't need a fully compliant ORB for Fresco support.

>- No way to hop firewalls or control connectivity
>
I don't know about firewalls with CORBA, but I know it's serious 
trouble. JacORB claims "support for HTTP tunneling" and to have 
"Appligator, an IIOP proxy".

>This also means that client-to-client communication should all be routed _through_ the server
>
I don't think that's a good idea. If I have a mail program and an 
address book running on a remote location and the display locally, I 
wouldn't want the mail program to route traffic to my display and back, 
nor would I even want the display machine to necessarily make the 
decision which address book server to use. The same thing for a mail 
program and the HTML renderer. The latter may run on the local display 
or on the remote computer, and in the latter case, it's none of the 
business of the local Fresco server.
This is something CORBA solves *very* nicely, by giving us a number of 
*generic* resource discovery mechanisms (IOR in a file, nameservice, 
trader, ...), created to suite very different needs, needs which our 
users will have, *too*. But you don't have to discuss about that design, 
you can just build on the thoughts and experiences others had, reuse 
existing specs and implementations. In the ideal case, the user can even 
choose the mechanism, without any Fresco or app support.

I think that is an extremely important (actually main) argument for 
CORBA: CORBA is not just useful for Fresco<->app communication, but also 
for client<->client communication.
Current GUI applications are mostly monolithic: The address book is 
usually built into the email client and another one in the phone app and 
if you want to use the addresses in a serial letter, you need yet 
another data source. And that's only the tip of the iceberg: I have for 
example a folder "Fred" on my filesystem for files related to my friend, 
a folder in my bookmarks, a folder in my email client for emails related 
to him, in the email client's address book one entry for him, in the 
Jabber client etc.etc.. What I want is to have one object for Fred and 
then not only have the email and Jabber client get his addresses from a 
central address book, but also to associate other objects like bookmarks 
and files/folders to that object. I think this would be a giant step 
forward in usability of computers - I could "reply" to an image file 
created by Fred. CORBA is the best hope I see for that, it seems to be 
best suited to me (standard, broad use in many different environments, 
many implementations). Many other projects tried that, e.g. Gnome and 
KDE, but didn't solve it completely and often didn't work across project 
boundaries.
My hope is that Fresco would encourage such interoperation between 
applications - partially by leading programmers towards CORBA, partially 
by papers, partially by just fitting nicely into all this. In such a 
world, Fresco using CORBA just makes sense.
Admittedly, that's a somewhat fantastic vision, but my point is that a 
programmer learning CORBA is an investion into the future, not just into 
Fresco.

>that clients can connect to the server is the only thing we can realistically assume
>
In CORBA, that's up to the local setup, where it's well-placed IMHO.

>- Basic model is of synchronous calls -- with CORBA, every network
>  operation must block waiting for a response.
>
I thought there were one-way messages, where you don't wait for a 
response? (See below)

If you want to go asyncronous, note that it's generally a *pain* to use 
for client programmers. I teared many hairs out when forced to use async 
processing where it wasn't appropriate - often, I just have a function 
call, and I need the result to go on in my execution flow. With async 
processing, I basically need a new function for every async function 
call, which makes it very hard to use the previous state (local vars). 
You have to manually match the callback to the call, for *every* 
invocation. It's *much* easier to just e.g. create a new thread at the 
beginning of a code string which will need to call long-delay functions 
and then block on every call. In many cases, not even that is necessary.
IIRC, you said you can optionally hide the asyncronousity from the 
programmer, allowing him to make syncronous calls in his code?

>  Aside from this inelegance and wastefulness, this is a source of
>  serious problems; we simply cannot safely call back to clients at
>  the moment, because there is no guarantee that they will reply, and
>  thus no guarantee that our ORB will ever give us back our flow of
>  control.
>
True. However, assuming that the scene graph is server-internal, there 
are not that many places where you call the client. The Callback 
interface is invoked in only 4 or 5 places, IIRC, for example.

>  There's an unimplemented specification (AMI) for working around this.
>
Is AMI (asynchronous method invocation) these one-way calls (I read 
about them shortly somewhere, don't remember exactly where)?

>  - This also (as a minor point) means that we have to use threads, which
>    I'm not entirely convinced is a good idea.
>
FYI, BeOS massively uses threads (tens of thousands, I've read 
somewhere) in the UI, with extraordinarily good results. IIRC, threads 
were mentioned as the main reason for BeOS' legendary responsiveness.

>    [3] I _think_ that even when CORBA locking was eliminated with my
>    shortcut patch
>
BTW, that, and esp. its analysis, was oustandingly good work. It's one 
of the reasons why I respect you so much and fear to disagree with you, 
but I have strong feelings on the subject of entriely removing CORBA 
from Fresco.
XXX

>  As for reliable one way calls?  I've heard rumors that the OMG will
>  eventually spit out yet another piece of paper that will solve all
>  our problems.  I'm skeptical.
>
:-)

>- Location transparency.
>
Well, the point is that you don't have to re-write or even re-organize 
all your code, if you later discover that you do need to move some parts 
to other address spaces. And Berlin/Fresco has a history of 
reorganization ;-).

>However, I do not see that we have any choice in the matter.
>
Overall, I only see 3 problems with CORBA in Fresco:
- Speed
- Stability (clients sabotaging server execution)
- Firewall
- Security (running untrusted clients)

Stability should be solved by removing CORBA from the scene graph.
This will probably also help speed significantly.
I am not optimistic that untrusted clients can be used securely at all, 
using any proposed scheme. I think I argued that in an earlier post.

>If someone finds an existing system that meets the needs outlined above,
>I will be very happy but if not, then I genuinely believe we must
>either create our own or give up entirely.
>
If we really can't find an existing infrastructure which suits Fresco's 
needs, then I think something is very wrong with computing. Components, 
IPC and remote communication is something almost every app needs in one 
form or the other, and IMHO there should be a general interface (with 
variations for the different needs) for it.

Sincerely,

Ben