[boost] Interest in Remote Procedure Call Library?

Subject: [boost] Interest in Remote Procedure Call Library?
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2010-02-06 21:52:26

I have been playing with some code and recently developed a very efficient, extensible, and easy to use API for performing remote procedure calls (with multiple protocols).   I am writing to gauge interest and get feedback on the user API.  The native "protocol" is a custom combined tcp/udp protocol using multi-cast for discovery, but it would be very easy to add a shared memory solution, a dbus, XML/RPC, CORBA, etc back end to the user api.  

Example:

class SomeClass
{
        public:
                int add( int a, int b ) { return a + b );
                void sub( int a, int b, int* result ) 
                {  
                        if(result) 
                                *result = a -b;
                }; 
                void inout( int& a ) { a += 5; }
};

META_INTERFACE( SomeClass,
        METHOD(add)
        METHOD(sub)	
        METHOD(inout)
)

// server

SomeClass   myclass;
Server		myserver( &myclass, "my.named.service" );

// client

RemoteInterface<SomeClass>  ri( "my.named.service" );
int result = ri.add(1,4); assert( result == 5 )
ri.sub( 5, 1, &result );  assert( result == 4 );
ri.inout(result);  assert( result == 9 );

API can support any type that is serializable.   It also supports the signal/slot paradigm.  SomeClass could have any number of base-classes both virtual and non-virtual.  

With respect to performance, it can perform 15,000+ synchronous (invoke, wait for return) operations per-second on localhost/linux.  Asynchronous operations are capable of 500,000+ invokes/sec.

The library doubles as a built-in reflection system allowing run time inspection member functions, parameter types, inheritance, etc.   

I am working to convince my employer (small company of 25) that contributing this library would bring more benefits than "costs" to the company.  The reasons I think it is a good idea
include:

1) Expose the company to more people (marketing)
2) We can give our customers an "open" API for communicating with our products 
2) Offload some of the development / maintenance / support to the open source community
3) I like open source and have personal reasons for wanting it free and open. 

So I need to get some more support to convince my employer that this will be a good move.  Active interest would be a good sign.  Other ideas on the positive aspects of contributing vs keeping it internal would also help me make my case. 

Thanks,
Dan