[boost] Re: RPC library

From: Jarl Lindrud (jlindrud_at_[hidden])
Date: 2005-03-03 17:28:42

Iain Hanson <Iain.Hanson <at> videonetworks.com> writes:
> 
> Here is an example CORBA client. And it doen not matter which ORB you
> use.
> 
> #include <iostream>
> #include "echoC.hpp" // generated from the idl file
> 
> int 
> main ( int ArgV , char * ArgV )
> {
>   try
>   {
>       // _var types are smart ptrs to ref counted objects.
>       CORBA::ORB_var Orb = CORBA::ORB_init ( ArgC , ArgV , "TAO");
> 
>       // get IOR from a file so we can talk to server
>       CORBA::Object_var Factory_Object = 
>                                   Orb->string_to_object ( ArgV [ 1 ] );
> 
>       // This is a CORBA safe downcast
>       My::Echo_Factory_var Factory = 
>                  My::Echo_Factory::_narrow ( Factory_Object.in( ) );
> 
>       My::Echo_Server_var EchoServer = 
>                               Factory->get_server ( ArgV [ 2 ] );
> 
>       CORBA::String_var Echoed = EchoServer-> ( "Hello World" );
> 
>   }
>   catch ( CORBA::Exception & E )
>   {
>       std::cerr << "CORBA exception raised!" << std::endl;
>   }
> }
> 
> I don't think 5 lines of code is exactly heavyweight. I could of done it
> in 3 lines if I did not use a factory, but that would have been
> unrealistic.

Depends on what's in the 5 lines.
> 
> I won't show the server but it 2 classes the factory publicly inherits
> from Echo_Factory and implements a single function get_server. Likewise
> like for EchoServer.

You're making my point for me. For something quick and dirty, who is going to 
want to type all that out? And before I do, I have to learn about IDL, _var 
types, safe downcasts, factories, CORBA::string's, etc, while in the back of my 
mind there's the nagging suspicion that I've missed some subtle detail 
somewhere. And whoever will be looking at my code needs to learn these things as 
well. I also have to modify the build process to handle the IDL files, and then 
find an ORB to build and link to. None of this is difficult, but I personally 
find it rather cumbersome, and above all, for my situation it's just plain 
unnecessary. All I wanted to do was to make a couple of remote calls between two 
C++ programs! Something along these lines seems to me much more proportional to 
the task at hand:

// server

RCF_BEGIN(I_Echo, "I_Echo")
  RCF_METHOD_R1(std::string, echo, std::string);
RCF_END(I_X);

struct Echo
{
  void std::string echo(std::string s) { return s; }
};
  
int main()
{
  RCF::RcfServer server(50001);
  server.bind<I_Echo,Echo>();
  server.start();
  return 0;
}

// client

RCF_BEGIN(I_Echo, "I_Echo")
  RCF_METHOD_R1(std::string, echo, std::string);
RCF_END(I_Echo);

int main()
{
  std::cout << RcfClient<I_Echo>("localhost", 50001).echo("ho hum");
  return 0;
}

>
> Because when you app grows you will have to re-write it. More likely, is
> that won't happen and people will re-invent the again. Take a look at
> the development of SOAP .
> 

I guess the argument boils down to this: does anyone write network applications 
for which CORBA-style scaleability is not a requirement? I would think so, but 
maybe I'm wrong.

RPC's don't scale too well, we both agree on that. But why do you think all 
applications need to scale? If I'm prototyping something, then the last thing in 
the world I need is scaleability, and I certainly wouldn't want the development 
cluttered and slowed because someone has decreed that we must all use CORBA 
because it scales so well.

Your position seems to be that programmers should not be afforded the option of 
choosing; they should just bite the bullet and always use CORBA. If they don't 
like that, then they should just avoid networking altogether.

/Jarl.