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.
Post by James KulpI 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?
Post by James KulpI 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.