thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Meier <ro...@bufferoverflow.ch>
Subject Re: Thrift in an embedded setting
Date Mon, 11 Jan 2016 20:04:16 GMT
Hi all

I think we should rework the existing cpp towards modern C++ to awoid a
second lib and generator to maintain.

The cpp_v2 branch from Konrad is a great place to start, the
modularization and testability is awesome!
As we decided to base on modern C++ such as C++11, I would like to
replace the existing ccp lib and generator instead of adding another one.

I guess this might also enable Thrift on bare metal with C++ compilers.

best!
-roger

Quoting Konrad Grochowski <hcorg@minions.org.pl>:

> 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
View raw message