I agree small incremental patches that can be evaluated on their
individual
merits is the best way to go. The beauty of thrift now is it's
simplicity.
I totally agree and I do not want this to change. I wanted to build the
multiple-services client and server and bumped into the fact that the
current API made it more difficult than needed to implement them. Because
of the pending change to Apache packages I saw an opportunity to make the
API easier for client and server implementers, so I summarized a number of
outstanding issues that were being discussed. I not only focused on things
that would be useful for me, but also included improvements proposed by
other (e.g. the compact format).
A lot of the changes I proposed do not affect the simplicity of Thrift,
but only concern how it is implemented.
At first glance a multiplexing server looked like a good idea to me.
After
thinking about it for a bit, I'm not clear on what benefit it has over
adding
new functions to existing services, or routing messages internally.
I want to expose a lot of fine-grained services instead of a few
coarse-grained ones. I also want to be able to enable or disable each
fine-grained service separately. If I have to use a single or a few
services, I will loose this flexibility. Also the single-resonsibility
principle for services is lost.
Routing messages internally is difficult to implement unless all functions
have the same parameters because Thrift does not support polymorphism.
Note: I see this as a feature and not a limitation. Introducing
polymorphism will, in my opinion, move away from the simplicity goal of
Thrift.
ZeroC Ice has a concept similiar to this (Facets) and numerous other
concepts.
The problem is that it's very complex system. The result is that your
code
becomes more tightly coupled with the underlying RPC system.
I absolutely want to prevent this. I know for sure it is possible to write
service implementations that can be used in a single-service or
multiple-services manner without impact on the code, i.e. a service
implementation would be totally unaware of how it is used:
- single service/multiple services
- synchronous/asynchronous
- sockets/servlets/JMS/e-mail/instant messaging/file/...
- ...
--
Kind regards,
Johan Stuyts
