[omniORB] Alternative transports

[James Kulp]

Hi Duncan,

We have successfully added our transport as a new transport into omniORB 
4.1.5.
There is plenty more testing to do and thus we're not ready for any real 
patching at this time.

I used the "unix" transport as a rough model, although ours is a bit 
different.

It wasn't exactly just like adding a new "plugin", but it wasn't too bad 
either.

Other than adding a new subdirectory (like tcp and unix and ssl), I had 
to touch a number of other files, noted below.

I would propose that we ultimately make a patch that includes the 
modifications to existing files, but that doesn't
include the new files.  I don't want to clutter up the files with 
IFDEFs, but that might be the cleanest at this time.

Of course with more time, the transport interface could be evolved to 
not require touching all these files and be
more of a pure plugin/driver.

Thoughts for how we should proceed?

Thanks,

Jim

./include/omniORB4/IOP.h
241a242
 >   static _core_attr const ComponentId TAG_OMNIORB_OCPI_TRANS;

./include/omniORB4/omniIOR.h
331a332,337
 >   static void  unmarshal_TAG_OMNIORB_OCPI_TRANS(const 
IOP::TaggedComponent&,
 >                         omniIOR&);
 >   static char* dump_TAG_OMNIORB_OCPI_TRANS(const IOP::TaggedComponent&);
 >   static void  add_TAG_OMNIORB_OCPI_TRANS(const char* filename);
 >
 >   ////
./include/omniORB4/omniURI.h
159a160,164
 >
 >   static char* unescapeKey(const char*& c, unsigned int& key_size);
 >   // Convert the escaped key string (as found in corbaloc: URIs),
 >   // into the unescaped version, which is really the data that
 >   // will be held in an octet sequence.
[This existing prototype above was moved here to make this function 
available to our transport code]

./src/lib/omniORB/orbcore/dir.mk:

Adding the new transport files, header paths, and libraries under
#ifdef  OMNIORB_CONFIG_OCPI

.cc files:
./src/lib/omniORB/orbcore/constants.cc
190c190
<
---
 > const IOP::ComponentId IOP::TAG_OMNIORB_OCPI_TRANS            = 
0x41545405;
228a229
 >   { IOP::TAG_OMNIORB_OCPI_TRANS, "TAG_OMNIORB_OCPI_TRANS" },
./src/lib/omniORB/orbcore/giopEndpoint.cc
110a111,113
 > #if defined(IncludeOcpiTransport)
 > OMNI_FORCE_LINK(ocpiTransportImpl);
 > #endif
./src/lib/omniORB/orbcore/objectAdapter.cc
741a742
 > "                          *\"giop:ocpi:<ocpi-endpoint>\"   |\n"
./src/lib/omniORB/orbcore/ior.cc
Several hundred lines of IOR-building stuff...
./src/lib/omniORB/orbcore/uri.cc
A hundred lines of address parsing stuff.


On 1/9/12 9:45 AM, Duncan Grisby wrote:
> On Thu, 2011-12-29 at 08:06 -0500, James Kulp wrote:
>
>> I am about to embark on an unavoidable task to port a custom ORB
>> transport to OmniORB.
> Can you tell us what for?  What does the transport look like?
>
>> I found the small transport.txt document and have perused the tcp
>> transport code and the unix transport code.
>>
>> The transport.txt document implies that it is also possible to plug in
>> at the GIOP level, but I cannot find any examples of this.
> You mean plug in something other than GIOP?  Although that it
> theoretically possible, I don't believe it has ever been done, and it
> probably won't work without some changes to the core code. The original
> design of the code was that GIOP_C and GIOP_S are subclasses of IOP_C
> and IOP_S, and you can implement other subclasses for other protocols.
>
> If you need to support something other than CDR marshalling, you'll have
> to hack things quite a lot. For performance, all the CDR marshalling is
> performed by inline functions (from cdrStream.h), so to marshal in any
> other way will involve serious surgery.
>
> Cheers,
>
> Duncan.
>