Ben,
That is a clever idea! I'm a little hesitant to take that approach, because
we'd have to implement it for each language that we use, and the ordinals
would have to be in code for each of these languages. I'll explore how we
might encode that data in the IDL somehow so that each language
implementation is generic.
Thanks,
David
On Mon, Apr 20, 2015 at 6:59 AM, Ben Craig <ben.cr...@ni.com> wrote:
> 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
> >
>
>
>
