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:06:07 GMT
Hey Roger,

I agree with the goal. However I think the easiest way to start is with a
new base (--gen cpp2). In this way we can get something in place for those
who need it now and then we can excommunicate the old lib whenever the
community is ok with it. The changes contemplated break the API, not
something we can just do to the old C++ lib without harming a lot of folks.

-Randy

On Mon, Jan 11, 2016 at 12:04 PM, Roger Meier <roger@bufferoverflow.ch>
wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message