Bryan Duxbury wrote:
What we're wondering about:
- Am I correct that you're permitted one service per socket? It
seems like you'd have to strike a balance between a single massive
service and having several ports open. Something about this doesn't
pass the sniff test for me. Are people really just defining one
massive service definition?
This is true - one service per socket. Typically, my services don't
get that big, and generally I'm not trying to cram more than one
service into a single interface. On occasion, I have used multiple
ports per server process to export multiple interfaces. Note that
Thrift is not meant to be something like XML-RPC where you can host
multiple services and provide discovery, etc - it's purpose built to
handle a single type of client-server communication.
If you use the HTTP transport, you can build a server that exposes
multiple services on the same port using different HTTP request paths.
We use this to expose two public services on slightly different paths
(https://www.evernote.com/edam/user vs. https://www.evernote.com/edam/note/)
Client support for HTTP transport exists for most of the languages,
although performance will vary depending on whether the HTTP framework
internally supports connection keep-alive and reuse. (E.g. Java does.)
Server-side support for HTTP requires a bit more work on your side.
- Is there a plan to transfer comments to the generated interfaces?
I have to keep peeking back at the IDL comments to see what exactly
it is I should be returning (or expecting). There's certainly an
argument here for clear method naming although I think you get my
point :)
At least in the Java and Ruby generators, if you comment an object
with /** */ (so-called javadoc comments), they will get transferred to
the generated code.
These comments will also be incorporated into the HTML documentation
output. E.g. this is auto-generated from our Thrift IDLs:
http://www.evernote.com/about/developer/api/ref/
