Clang server with Thrift

This is my first post on this mailing list, so hello to everybody :wink:

I wanted to use Clang for building C++ IDE in java.
Unlucky as you all know there is no default API for java (nor for
anything else than C and python).
I created drop-in replacement by auto generating java JNA API from C,
but it's a bit messy (for example doesn't have enums; if you want you
can find it here: GitHub - pkukielka/jclang: Java bindings for Clang 3.3).
Actually this is general problem, not only for java.
Possible solution could be to use some external Clang server with API
defined in some standard, easy to implement format (like JSON). There
was already proposal of something like that
(http://clang-developers.42468.n3.nabble.com/RFC-A-proposal-for-a-Clang-based-service-architecture-td4024449.html)
but there are some problems with this design (like using own binary
protocol). Besides I don't know if any work on this was started.

IMHO possible solution to the problem would be to use Thrift to define
Clang API.
It would be based on current C API, with changes when needed (Thrift
support only passing by value).
That would allow us to generate C++ server and clients in virtually
any language (C++, C#, Cocoa, D, Delphi, Erlang, Haskell, Java, OCaml,
Perl, PHP, Python, Ruby, Smalltalk). Server would require some work
(but still much, much less than in original proposal) and clients
would require no work at all to create.

I already started working on this, for my own use if not for anything else.
But I'm curious about your opinions: does it make sense, would you
benefit from something like that?
Or maybe you see any serious problems with this Thrift approach?
Feel free to share your thoughts with me.

Thanks,
Peter

Have you seen this

Yes, I mentioned it in my post. But:
a) It have other goals; that ClangService is aiming for building
external service easy to use from lightweight text editors.
It doesn't simplify porting Clang API to other languages
b) It's only proposal, as far as I know no work was started on that?
And taking in account all details from the proposal it will take
months to build something working.
Porting libclang API to thrift should be doable in ~2 weeks maybe.

I have never used Thrift, but is a Thrift API going to be easier to
bind to than the existing C API? I'm pretty sure that every language
can bind to a C API.

-- Sean Silva

Yeah, you can bind to C API in most languages, but you still need to
write some king of wrapper ofr it.
This means that for every single language you need to maintain ~1000
lines of code.

Thrift works in other way. When you define API using Thrift you can
automatically generate server and client in
several languages. Clang server need to be written in C++ so you can
implement its methods using
calls to Clang library. But all the clients can be auto generated and
doesn't require any work at all.
This means you need to maintain only Thrift API and it's
implementation on the server side.

The only downside of this method is that you need to always run second
process (server) and communication
with it is more expensive than direct call (however I don't believe
that latency would be significant here).