David,
If you method ordinals today, without changing the generator, and without
even changing Apache Thrift source, you can hack it at the protocol level.
Inherit from your protocol of choice, and then override readMessageBegin
and writeMessageBegin, and you can translate from the code generated
string to your own over-the-wire ordinal / hash value. Similar tricks may
be possible on the multiplexing front as well.
This has the disadvantage of putting the ordinals in code, as opposed to
putting them in the .thrift file, but it should be less work short term.
From: Randy Abernethy <randy.aberne...@gmail.com>
To: "dev@thrift.apache.org" <dev@thrift.apache.org>,
Date: 04/19/2015 06:06 PM
Subject: Re: method names sent as strings
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
>
