Thanks for your reply, Randy! Responses inline below.
On Sun, Apr 19, 2015 at 4:05 PM, Randy Abernethy <randy.aberne...@gmail.com>
wrote:
>
>
>
> 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.
>
>
Good point about service inheritance. I'm not using that feature at the
moment, but I agree collisions would be hard to avoid in that environment.
One way around it might be to encode a (inheritance depth, method ordinal)
tuple, as a sort of auto-generated integer namespace for the method ordinal
to live in. The service hierarchy could be walked at compile time to
determine the depth of each service.
>
> 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.
>
>
I might give this a shot, actually. We're using C++, Python, and ObjC
currently. If I end up tackling it for those 3 languages, I'll let
thrift-dev know.
>
>
> 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.
>
>
The simplicity of the multiplexing implementation is attractive, I agree.
It also allows for a lot of flexibility. For now, we can simply use short
service names. In the future, I'm sure we could build something that maps
service names to unique ordinals or short strings.
Thanks,
David
> 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
> >
>
