On Thu, Mar 6, 2014 at 12:13 PM, Thejas Nair <[EMAIL PROTECTED]> wrote:
As with any rule, there are always exceptions. However, looking at the
new API's I don't see an instance where it would would have been
harmful to use this model. Exceptions should be extremely rare since
thousands of RPC implementations successfully use the request/response
model. However, as always, it would be up to the developers working on
the change to make this call. They'd do so knowing they are going
against the guideline and could be asked to justify why they are doing
RPC methods are "special". They are published to the world and
therefore cannot be easily modified or refactored. Once we create a
new RPC method, we are stuck with it for a very long time. In this
way, Thrift is rather strange in that it allows you to exposed the api
signatures. The request/response model is far more common.
Therefore, if we were creating create_table from scratch, I would
suggest we use:
That way, we can add optional arguments such as "environment context"
very easily. Although, I'd love to take credit for this idea, I didn't
just come up with this myself. This is a standard way of handling RPC.
There will be cases where we'll need similar methods. This point where
is with the request/response model, adding a single parameter doesn't
require an entirely new method. The developers working on the change
would have to make the call as to whether a new functionality requires
a new API or can be handled within the current API.
The "Output" and "Input" names do feel odd. As I said above.
Request/Response are standard names for these kinds of objects. Today,
for a method like the one above, it may feel like overheard or extra
work. However, in the future when you want to add another parameter
such as "isFilter" or "encoding" etc, then the insurance pays off big