I have a Thrift service implemented as a C++ library. It is used locally to serve a database to multiple local client applications.
We also have a web site that is mostly implemented in java. We have identified
a requirement for the web site java code to do something that is both
complicated, and is already implemented in my Thrift service C++ library.
We could expose the C++ service to the java code by writing a daemon to run on
the web site machines. However, there is a concern about scalability. There is
also a concern that the "client side" developers would need to deliver the
daemon binary to he "server side" developers. Essentially it makes us maintain
another product, even if it's only distributed internally. (There is also the
issue that we really have more than one of these C++ library implementations
that would be useful to java. We really worry about the performance if the java
needs to perform hundreds of operations using the C++ library and the interface
is service-based.)
It was suggested that we investigate whether we could use SWIG to wrap the C++
library. That way, our java code could use the functionality by linking a
library, rather than sending a message to a service.
The first step of that investigation was to try and wrap a C++ class definition
generated by the Thrift compiler.
That fails, but only because of the nested structure definition for the __isset
member of the class. For instance, if my Thrift generated class is named foo,
the code in foo_types.h looks like this:
class foo {
... other stuff
struct __isset {
__isset() : dataMember0(false), dataMember1(false) {}
bool dataMember0;
bool dataMember1;
} __isset;
};
This is convenient, but SWIG chokes on the nested structure definition. This
could be avoided if the __isset class were defined separately. Then foo_types.h
would look more like this:
typedef struct foo__isset {
foo__isset() : dataMember0(false), dataMember1(false) {}
bool dataMember0;
bool dataMember1;
} foo__isset;
class foo {
... other stuff
foo__isset __isset;
};
As far as I can tell, this has no effect on any of the code. It does pollute
the namespace a little bit, but it seems acceptable to me.
Would making a change like this, possibly dependent on a compiler command line
flag, be acceptable to the developer community? Or is using SWIG on Thrift
objects just abhorrent?
- Rush
smime.p7s
Description: S/MIME cryptographic signature
