From ... Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!news.tele.dk!148.122.208.68!news2.oke.nextra.no!nextra.com!news01.chello.no!Norway.EU.net!127.0.0.1!nobody From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: corba or sockets? Date: 31 Oct 2000 00:56:07 +0000 Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net Lines: 85 Message-ID: <3181942567437276@naggum.net> References: <3181900924130896@naggum.net> <39FDFFE6.5C12@synquiry.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: oslo-nntp.eunet.no 972954085 26667 195.0.192.66 (31 Oct 2000 01:01:25 GMT) X-Complaints-To: newsmaster@eunet.no NNTP-Posting-Date: 31 Oct 2000 01:01:25 GMT mail-copies-to: never User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Xref: supernews.google.com comp.lang.lisp:2948 * Jon S Anthony | 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