Hey Dave,
I can’t speak to the original motivations, but one view on the methods
front might be that method ordinals would be a little more prone to
collisions than method names in scenarios where service inheritance is in
place (particularly if the service interfaces are controlled by separate
parties). In contrast, parameters are all defined in a single file and have
an explicit scope. Perhaps more material, the platform was originally
focused on backend services running in data centers with >1KB MTUs (rather
than 27 bytes). I doubt anyone would use that as an argument against
efficiency today however.
The implementation of method ordinals would require an update to all of the
language generators (>20), a sizable piece of work. So while method
ordinals are a feature with clear benefits, it would have to overcome some
inertia to become a reality. On the upside, method ordinals could be added
language by language as an option without too much disruption [e.g. thrift
--use_method_ordinals might use the ordinal (“1”) from the IDL rather than
the name (“fetchBookingData“) on the wire and both could be supported on
the processor side]. Internally, the IDL parser could supply ordinals and
names, allowing and the old generators to ignore the ordinals until support
can be added.
On the service front, multiplexing was only added in 0.9.1 as I recall. One
of the attractive aspects was the layering nature of the multiplexing
client and processor. Multiplexing does not impact the IDL, compiler or any
of the existing library code. Also you need not use it. If you want
multiplexing and want shorter service names you could use ordinal strings
today (e.g. service 1 {...}), perhaps defining more descriptive macros for
end users. Adding proper service ordinals to the IDL would require more
significant compiler and lib updates and, given service names are
essentially global, the opportunity for collision is more substantial. I
think service ordinals offer less bang for the buck than method ordinals.
Might make a good follow on project if method ordinals got off the ground.
Nice discussion topic!
Best,
Randy
On Fri, Apr 17, 2015 at 4:59 PM, David Shoemaker <mrs...@gmail.com> wrote:
> Thrift dev,
>
> I was wondering why the decision was made to serialize method names as
> strings. A helpful thrifter on IRC (JensG) pointed me to
> https://thrift.apache.org/static/files/thrift-20070401.pdf, which states
> that hashing method names was considered, but was found to be problematic.
>
> I can't argue with that, but I do wonder why we can't simply tag each
> method with a ": 1", ": 2", etc. like we do with struct members and method
> arguments.
>
> I've also been using service multiplexing and noticed that service names
> are sent as strings with each method call as well. It would seem that
> tagging services with integers could be a good feature as well, given that
> varint encoding would then take the (service name, method name) tuple down
> to two bytes in many cases.
>
> The reason I ask is that I'm using thrift over BLE (bluetooth low energy),
> so my MTUs are small enough that a few extra bytes leads to extra packets,
> which increases latency.
>
> Thanks,
> David
>
