thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Abernethy <randy.aberne...@gmail.com>
Subject Re: Thrift in an embedded setting
Date Mon, 11 Jan 2016 22:00:00 GMT
Hey Konrad,

Sounds great. Maybe the easiest thing to do is to get a base working and
then pull in everything we can from your repo.

Best,
Randy

On Mon, Jan 11, 2016 at 11:50 AM, Konrad Grochowski <hcorg@minions.org.pl>
wrote:

> Hi Randy,
>
> Do you think we could somehow merge our cpp2 efforts? (
> https://github.com/hcorg/thrift/tree/cpp_v2)
> It's my old branch, had to put it on little hiatus, yet I think some parts
> of it could be useful.
>
> Best regards,
> Konrad
>
> W dniu 11.01.2016 o 20:16, Randy Abernethy pisze:
>
> Hi Dane and Tomas,
>>
>> Great to hear we have a few people willing to pull the oars. I'll get our
>> cpp2 lib sanitized this week and post a jira/patch in a few days. Then we
>> can take it from there.
>>
>> Best,
>> Randy
>>
>>
>> On Mon, Jan 11, 2016 at 11:14 AM, Dane Mason <danem.mason@gmail.com>
>> wrote:
>>
>> Hey Randy,
>>>
>>> That sounds perfect for our use case. I would love to contribute. Let me
>>> know when you have more details.
>>>
>>> Dane
>>>
>>> On Sun, Jan 10, 2016 at 9:44 AM, Randy Abernethy <
>>> randy.abernethy@gmail.com>
>>> wrote:
>>>
>>> Hey Dane,
>>>>
>>>> My shop has a C++11 (no boost) language implementation for thrift. We
>>>>
>>> have
>>>
>>>> only built out the generator (--gen cpp2) TBinaryProtocol,
>>>> TCompactProtocol, framing and basic socket transports. I have tried to
>>>>
>>> get
>>>
>>>> some help cleaning this up for public consumption but so far no takers.
>>>> Also other quarters have threatened to post such a code base which has
>>>> caused us to hold off (don't want multiple versions of this stuff in the
>>>> trunk). If you are willing to contribute I'll try to package things up
>>>>
>>> for
>>>
>>>> a commit this week so that we can get the community to pitch in and
>>>>
>>> finish
>>>
>>>> off a basic C++11 lib. Should work great for your purposes (which is
>>>> exactly what we use it for).
>>>>
>>>> Best,
>>>> Randy
>>>>
>>>> On Sat, Jan 9, 2016 at 6:20 PM, Dane Mason <danem.mason@gmail.com>
>>>>
>>> wrote:
>>>
>>>> Sorry I should have been more clear. C++ is fine, but the boost
>>>>>
>>>> dependency
>>>>
>>>>> is problematic.
>>>>>
>>>>> Dane
>>>>>
>>>>> On Saturday, January 9, 2016, Randy Abernethy <
>>>>>
>>>> randy.abernethy@gmail.com
>>>
>>>> wrote:
>>>>>
>>>>> Do you need a C impel or can you use C++11 on the embedded sys?
>>>>>>
>>>>>> On Saturday, January 9, 2016, Dane Mason <danem.mason@gmail.com
>>>>>> <javascript:;>> wrote:
>>>>>>
>>>>>> Hi, I'm part of a project that makes heavy use of Thrift and it's
>>>>>>>
>>>>>> RPC
>>>
>>>> functionality across Java, C++, and Python. This project now needs
>>>>>>>
>>>>>> to
>>>
>>>> incorporate an embedded component with 256kb ram running on a
>>>>>>>
>>>>>> CortexM3.
>>>>
>>>>> After a bit of research, I've decided that there is no straight
>>>>>>>
>>>>>> forward
>>>>
>>>>> way
>>>>>>
>>>>>>> of using Thrift in this context out of the box. We are not willing
>>>>>>>
>>>>>> to
>>>
>>>> bring
>>>>>>
>>>>>>> GLib in as a dependency, nor are we willing to use C++ and Boost.
>>>>>>>
>>>>>> What
>>>>
>>>>> we
>>>>>
>>>>>> simply need is a way to reuse the binary protocol and most
>>>>>>>
>>>>>> importantly,
>>>>
>>>>> the
>>>>>>
>>>>>>> IDL used throughout the rest of the project. We are using many
>>>>>>>
>>>>>> large
>>>
>>>> structs, so maintaining 4 hand written implementations across our 4
>>>>>>> languages doesn't make sense.
>>>>>>>
>>>>>>> Some solutions I've considered:
>>>>>>>
>>>>>>> 1. Manually write code serialize and deserialize the thrift binary
>>>>>>> protocol.
>>>>>>> - We are dealing with many large structs, and ensuring correctness
>>>>>>>
>>>>>> of
>>>
>>>> this
>>>>>>
>>>>>>> handwritten code is tedious and error prone.
>>>>>>>
>>>>>>> 2. Use a JSON protocol and use existing JSON parsers on the C
side.
>>>>>>> - Again error prone, may not be performant enough for our use
case.
>>>>>>>
>>>>>>> 3. *Possibly *create something like a "TFlatBufferProtocol" 
(or
>>>>>>>
>>>>>> any
>>>
>>>> other
>>>>>>
>>>>>>> Serialization format with an IDL)
>>>>>>> - I haven't looked into this in depth, it seems messy and hard
to
>>>>>>>
>>>>>> maintain.
>>>>>>
>>>>>>> I'd appreciate any advice you all have to offer here.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Dane
>>>>>>>
>>>>>>>
>
> ---
> Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie
> antywirusowe Avast.
> https://www.avast.com/antivirus
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message