Thrift in an embedded setting

[Dane Mason <da...@gmail.com>]

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

Re: Thrift in an embedded setting

[Chris Seto <ch...@gmail.com>]

I've been watching this thread because I also use thrift in an embedded
setting, although we use it on top of embedded Linux since we didn't want
to deal with trying to port it to actual "bare metal" embedded.

Anyway, I have nothing real to contribute at the moment, but I will say
that a proper RPC package for bare metal embedded targets is /sorely/
needed. It'd be awesome to see Thrift or something like it running bare
metal, as long as the overhead can be reasonably small.

Chris

On Sat, Jan 9, 2016 at 5:02 PM, Dane Mason <da...@gmail.com> 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
>



-- 
Chris Seto
Check out my blog!
http://www.chrisseto.com

Re: Thrift in an embedded setting

[刘畅 <li...@hotmail.com>]

Dear Randy,

I’m interested in your project as well, please send me the link as well.

Look forward to creating things with you guys.

Best,
Tomas

> 在 2016年1月11日，上午1:44，Randy Abernethy <ra...@gmail.com> 写道：
> 
> 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 <da...@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 <ra...@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
>>>> 
>>> 
>> 

Re: Thrift in an embedded setting

[Randy Abernethy <ra...@gmail.com>]

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 <hc...@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 <da...@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 <da...@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
>
>

Re: Thrift in an embedded setting

[刘畅 <li...@hotmail.com>]

I notice that U have merged the branch.

So, where exactly should we start?

> 在 2016年1月13日，上午1:55，Konrad Grochowski <hc...@minions.org.pl> 写道：
> 
> Hey Tomas,
> 
> I'll try to merge/rebase it against master and include recent changes in c++ lib into c++ v2 lib, probably this weekend (I hope I'll find some time).
> 
> As for C++11 - quick answer: because then at some point Thrift would have to introduce std17 or std14 etc :)
> Long answer - when I started my branch there was some discussion which lead to following - Thrift should have one C++ library for "the best of modern C++", which should be updated along with new compilers, new language and library features etc. This library should be named cpp v2 to not mix with any current new versions of C++ standard, as we want Thrift to be able to make this library compatible with current newest standard, be it std11 or std23. At some point this library should become standard (--gen cpp) and most new users should be happy. Current c++ library should be kept as "most common subset of C++ compilers features" library, to enable Thrift on some older or outdated environments. As for keeping multiple libs for cpp11, cpp14, cpp17 etc - it would just add too big maintenance cost to Thrift.
> 
> Best regards,
> Konrad
> 
> W dniu 2016-01-12 o 17:24, 刘畅 pisze:
>> Dear Konrad,
>> 
>> It’s exciting to see the effort here.
>> 
>> I’ve checked your branch and it’s really a little out of date.
>> 
>> Why not merge the modification lately and let’s plan it out together?
>> 
>> as for the generator, is it nice to call it cpp_v2? why not just use cpp version instead?
>> 
>> such as “—gen cpp_std11 ”
>> 
>> Best regard,
>> 
>> Tomas
>> 
>>> 在 2016年1月12日，下午5:37，Konrad Grochowski <hc...@minions.org.pl> 写道：
>>> 
>>> Hey All,
>>> 
>>> Few thoughts from previous discussion about C++ >= 11:
>>> - we have to keep old C++ lib (at least for a while) as C++11 lib would break iface compatibility
>>> - to avoid confusion at some point we agreed to use cpp_v2 name for new lib, so no user would ask "What is C++2?" (it's not perfect solution, still at least it's some solution). Current C++ lib should be renamed to cpp_v1, and "--gen cpp" should be an alias for cpp_v1, and later (1.0? 1.1? 2.0?) changed to cpp_v2 (keeping v1 for backward compatibility)
>>> 
>>> As for my branch:
>>> - it is probably a little bit outdated (haven't merged or rebased it for a while)
>>> - does not include CMake build files
>>> - Contains full copy of cpp_v1 lib, but with std::shared_ptr and std::thread instead of boost counterparts (boost usage is reduced significantly).
>>> - Optional fields are now using boost::optional (we need to check - maybe some compilers already support C++17 std::optional, so we could switch to that - C++17 will probably be released, before cpp_v2 become standard :) )
>>> - I've simplified ThreadManager, but it's not tested
>>> - while writing compiler I stopped at generating Processors and I think that's the last thing that is missing.
>>> 
>>> Best regards,
>>> Konrad
>>> 
>>> W dniu 2016-01-12 o 00:12, Roger Meier pisze:
>>>> Yes Randy, that's it!
>>>> 
>>>> I just found another issue about std::shared_ptr
>>>> https://issues.apache.org/jira/browse/THRIFT-2221
>>>> 
>>>> We can easily switch to boost-less code generation in place within the
>>>> compiler by using the new, modular and testable code from Konrad and
>>>> fine tune the C++ library for bare metal systems via CMake.
>>>> 
>>>> good afternoon, good evening, and good night!
>>>> -roger
>>>> 
>>>> PS: good morning ;-)
>>>> 
>>>> Quoting Randy Abernethy <ra...@gmail.com>:
>>>> 
>>>>> Most boost usage in Thrift is header based. The C++ lib "API" today uses
>>>>> boost::shared_ptr liberally and there are lots of other small incursions.
>>>>> While the elegance of Boost is uncontested, it is another dependency and as
>>>>> far as the Thrift C++ lib is concerned, it is redundant in the context of
>>>>> C++ >= 11. There are also boost thread bits which are lib based. Again you
>>>>> can work around this stuff but it is much easier, and at no cost of
>>>>> functionality, to just use C++11 these days.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <st...@stureynolds.com>
>>>>> wrote:
>>>>> 
>>>>>> Just out of interest, what's the nature of Thrift's dependency on Boost?
>>>>>> 
>>>>>> My recollection (also from embedded systems), is that *much* (but not
>>>>>> all) of Boost doesn't cause any real library dependencies because so
>>>>>> much of the Boost code is provided in full as template in header files
>>>>>> (i.e. it does not necessarily generate linker dependencies on boost
>>>>>> libraries).
>>>>>> 
>>>>>> Is this the case for Thrift's use of boost? Does it require some
>>>>>> linking against a boost library -- and could that dependency be cut?
>>>>>> 
>>>>>> - Stu
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
>>>>>> <ra...@gmail.com> wrote:
>>>>>>> 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 <ro...@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 <hc...@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 <da...@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 <da...@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
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>> 
> 

Re: Thrift in an embedded setting

[Konrad Grochowski <hc...@minions.org.pl>]

Hey Tomas,

I'll try to merge/rebase it against master and include recent changes in 
c++ lib into c++ v2 lib, probably this weekend (I hope I'll find some time).

As for C++11 - quick answer: because then at some point Thrift would 
have to introduce std17 or std14 etc :)
Long answer - when I started my branch there was some discussion which 
lead to following - Thrift should have one C++ library for "the best of 
modern C++", which should be updated along with new compilers, new 
language and library features etc. This library should be named cpp v2 
to not mix with any current new versions of C++ standard, as we want 
Thrift to be able to make this library compatible with current newest 
standard, be it std11 or std23. At some point this library should become 
standard (--gen cpp) and most new users should be happy. Current c++ 
library should be kept as "most common subset of C++ compilers features" 
library, to enable Thrift on some older or outdated environments. As for 
keeping multiple libs for cpp11, cpp14, cpp17 etc - it would just add 
too big maintenance cost to Thrift.

Best regards,
Konrad

W dniu 2016-01-12 o 17:24, 刘畅 pisze:
> Dear Konrad,
>
> It’s exciting to see the effort here.
>
> I’ve checked your branch and it’s really a little out of date.
>
> Why not merge the modification lately and let’s plan it out together?
>
> as for the generator, is it nice to call it cpp_v2? why not just use cpp version instead?
>
> such as “—gen cpp_std11 ”
>
> Best regard,
>
> Tomas
>
>> 在 2016年1月12日，下午5:37，Konrad Grochowski <hc...@minions.org.pl> 写道：
>>
>> Hey All,
>>
>> Few thoughts from previous discussion about C++ >= 11:
>> - we have to keep old C++ lib (at least for a while) as C++11 lib would break iface compatibility
>> - to avoid confusion at some point we agreed to use cpp_v2 name for new lib, so no user would ask "What is C++2?" (it's not perfect solution, still at least it's some solution). Current C++ lib should be renamed to cpp_v1, and "--gen cpp" should be an alias for cpp_v1, and later (1.0? 1.1? 2.0?) changed to cpp_v2 (keeping v1 for backward compatibility)
>>
>> As for my branch:
>> - it is probably a little bit outdated (haven't merged or rebased it for a while)
>> - does not include CMake build files
>> - Contains full copy of cpp_v1 lib, but with std::shared_ptr and std::thread instead of boost counterparts (boost usage is reduced significantly).
>> - Optional fields are now using boost::optional (we need to check - maybe some compilers already support C++17 std::optional, so we could switch to that - C++17 will probably be released, before cpp_v2 become standard :) )
>> - I've simplified ThreadManager, but it's not tested
>> - while writing compiler I stopped at generating Processors and I think that's the last thing that is missing.
>>
>> Best regards,
>> Konrad
>>
>> W dniu 2016-01-12 o 00:12, Roger Meier pisze:
>>> Yes Randy, that's it!
>>>
>>> I just found another issue about std::shared_ptr
>>> https://issues.apache.org/jira/browse/THRIFT-2221
>>>
>>> We can easily switch to boost-less code generation in place within the
>>> compiler by using the new, modular and testable code from Konrad and
>>> fine tune the C++ library for bare metal systems via CMake.
>>>
>>> good afternoon, good evening, and good night!
>>> -roger
>>>
>>> PS: good morning ;-)
>>>
>>> Quoting Randy Abernethy <ra...@gmail.com>:
>>>
>>>> Most boost usage in Thrift is header based. The C++ lib "API" today uses
>>>> boost::shared_ptr liberally and there are lots of other small incursions.
>>>> While the elegance of Boost is uncontested, it is another dependency and as
>>>> far as the Thrift C++ lib is concerned, it is redundant in the context of
>>>> C++ >= 11. There are also boost thread bits which are lib based. Again you
>>>> can work around this stuff but it is much easier, and at no cost of
>>>> functionality, to just use C++11 these days.
>>>>
>>>>
>>>>
>>>> On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <st...@stureynolds.com>
>>>> wrote:
>>>>
>>>>> Just out of interest, what's the nature of Thrift's dependency on Boost?
>>>>>
>>>>> My recollection (also from embedded systems), is that *much* (but not
>>>>> all) of Boost doesn't cause any real library dependencies because so
>>>>> much of the Boost code is provided in full as template in header files
>>>>> (i.e. it does not necessarily generate linker dependencies on boost
>>>>> libraries).
>>>>>
>>>>> Is this the case for Thrift's use of boost? Does it require some
>>>>> linking against a boost library -- and could that dependency be cut?
>>>>>
>>>>> - Stu
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
>>>>> <ra...@gmail.com> wrote:
>>>>>> 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 <ro...@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 <hc...@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 <da...@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 <da...@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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>

Re: Thrift in an embedded setting

[刘畅 <li...@hotmail.com>]

Dear Konrad,

It’s exciting to see the effort here.

I’ve checked your branch and it’s really a little out of date.

Why not merge the modification lately and let’s plan it out together?

as for the generator, is it nice to call it cpp_v2? why not just use cpp version instead?

such as “—gen cpp_std11 ”

Best regard,

Tomas

> 在 2016年1月12日，下午5:37，Konrad Grochowski <hc...@minions.org.pl> 写道：
> 
> Hey All,
> 
> Few thoughts from previous discussion about C++ >= 11:
> - we have to keep old C++ lib (at least for a while) as C++11 lib would break iface compatibility
> - to avoid confusion at some point we agreed to use cpp_v2 name for new lib, so no user would ask "What is C++2?" (it's not perfect solution, still at least it's some solution). Current C++ lib should be renamed to cpp_v1, and "--gen cpp" should be an alias for cpp_v1, and later (1.0? 1.1? 2.0?) changed to cpp_v2 (keeping v1 for backward compatibility)
> 
> As for my branch:
> - it is probably a little bit outdated (haven't merged or rebased it for a while)
> - does not include CMake build files
> - Contains full copy of cpp_v1 lib, but with std::shared_ptr and std::thread instead of boost counterparts (boost usage is reduced significantly).
> - Optional fields are now using boost::optional (we need to check - maybe some compilers already support C++17 std::optional, so we could switch to that - C++17 will probably be released, before cpp_v2 become standard :) )
> - I've simplified ThreadManager, but it's not tested
> - while writing compiler I stopped at generating Processors and I think that's the last thing that is missing.
> 
> Best regards,
> Konrad
> 
> W dniu 2016-01-12 o 00:12, Roger Meier pisze:
>> Yes Randy, that's it!
>> 
>> I just found another issue about std::shared_ptr
>> https://issues.apache.org/jira/browse/THRIFT-2221
>> 
>> We can easily switch to boost-less code generation in place within the
>> compiler by using the new, modular and testable code from Konrad and
>> fine tune the C++ library for bare metal systems via CMake.
>> 
>> good afternoon, good evening, and good night!
>> -roger
>> 
>> PS: good morning ;-)
>> 
>> Quoting Randy Abernethy <ra...@gmail.com>:
>> 
>>> Most boost usage in Thrift is header based. The C++ lib "API" today uses
>>> boost::shared_ptr liberally and there are lots of other small incursions.
>>> While the elegance of Boost is uncontested, it is another dependency and as
>>> far as the Thrift C++ lib is concerned, it is redundant in the context of
>>> C++ >= 11. There are also boost thread bits which are lib based. Again you
>>> can work around this stuff but it is much easier, and at no cost of
>>> functionality, to just use C++11 these days.
>>> 
>>> 
>>> 
>>> On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <st...@stureynolds.com>
>>> wrote:
>>> 
>>>> Just out of interest, what's the nature of Thrift's dependency on Boost?
>>>> 
>>>> My recollection (also from embedded systems), is that *much* (but not
>>>> all) of Boost doesn't cause any real library dependencies because so
>>>> much of the Boost code is provided in full as template in header files
>>>> (i.e. it does not necessarily generate linker dependencies on boost
>>>> libraries).
>>>> 
>>>> Is this the case for Thrift's use of boost? Does it require some
>>>> linking against a boost library -- and could that dependency be cut?
>>>> 
>>>> - Stu
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
>>>> <ra...@gmail.com> wrote:
>>>> > 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 <ro...@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 <hc...@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 <da...@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 <da...@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
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> 
>> 
>> 
> 

Re: Thrift in an embedded setting

[Konrad Grochowski <hc...@minions.org.pl>]

Hey All,

Few thoughts from previous discussion about C++ >= 11:
  - we have to keep old C++ lib (at least for a while) as C++11 lib 
would break iface compatibility
  - to avoid confusion at some point we agreed to use cpp_v2 name for 
new lib, so no user would ask "What is C++2?" (it's not perfect 
solution, still at least it's some solution). Current C++ lib should be 
renamed to cpp_v1, and "--gen cpp" should be an alias for cpp_v1, and 
later (1.0? 1.1? 2.0?) changed to cpp_v2 (keeping v1 for backward 
compatibility)

As for my branch:
  - it is probably a little bit outdated (haven't merged or rebased it 
for a while)
  - does not include CMake build files
  - Contains full copy of cpp_v1 lib, but with std::shared_ptr and 
std::thread instead of boost counterparts (boost usage is reduced 
significantly).
  - Optional fields are now using boost::optional (we need to check - 
maybe some compilers already support C++17 std::optional, so we could 
switch to that - C++17 will probably be released, before cpp_v2 become 
standard :) )
  - I've simplified ThreadManager, but it's not tested
  - while writing compiler I stopped at generating Processors and I 
think that's the last thing that is missing.

Best regards,
Konrad

W dniu 2016-01-12 o 00:12, Roger Meier pisze:
> Yes Randy, that's it!
>
> I just found another issue about std::shared_ptr
> https://issues.apache.org/jira/browse/THRIFT-2221
>
> We can easily switch to boost-less code generation in place within the
> compiler by using the new, modular and testable code from Konrad and
> fine tune the C++ library for bare metal systems via CMake.
>
> good afternoon, good evening, and good night!
> -roger
>
> PS: good morning ;-)
>
> Quoting Randy Abernethy <ra...@gmail.com>:
>
>> Most boost usage in Thrift is header based. The C++ lib "API" today uses
>> boost::shared_ptr liberally and there are lots of other small 
>> incursions.
>> While the elegance of Boost is uncontested, it is another dependency 
>> and as
>> far as the Thrift C++ lib is concerned, it is redundant in the 
>> context of
>> C++ >= 11. There are also boost thread bits which are lib based. 
>> Again you
>> can work around this stuff but it is much easier, and at no cost of
>> functionality, to just use C++11 these days.
>>
>>
>>
>> On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <st...@stureynolds.com>
>> wrote:
>>
>>> Just out of interest, what's the nature of Thrift's dependency on 
>>> Boost?
>>>
>>> My recollection (also from embedded systems), is that *much* (but not
>>> all) of Boost doesn't cause any real library dependencies because so
>>> much of the Boost code is provided in full as template in header files
>>> (i.e. it does not necessarily generate linker dependencies on boost
>>> libraries).
>>>
>>> Is this the case for Thrift's use of boost? Does it require some
>>> linking against a boost library -- and could that dependency be cut?
>>>
>>> - Stu
>>>
>>>
>>>
>>> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
>>> <ra...@gmail.com> wrote:
>>> > 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 
>>> <ro...@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 <hc...@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 
>>> <da...@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 
>>> <da...@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
>>> >>>
>>> >>
>>> >>
>>> >>
>>>
>
>

Re: Thrift in an embedded setting

[Roger Meier <ro...@bufferoverflow.ch>]

Yes Randy, that's it!

I just found another issue about std::shared_ptr
https://issues.apache.org/jira/browse/THRIFT-2221

We can easily switch to boost-less code generation in place within the
compiler by using the new, modular and testable code from Konrad and
fine tune the C++ library for bare metal systems via CMake.

good afternoon, good evening, and good night!
-roger

PS: good morning ;-)

Quoting Randy Abernethy <ra...@gmail.com>:

> Most boost usage in Thrift is header based. The C++ lib "API" today uses
> boost::shared_ptr liberally and there are lots of other small incursions.
> While the elegance of Boost is uncontested, it is another dependency and as
> far as the Thrift C++ lib is concerned, it is redundant in the context of
> C++ >= 11. There are also boost thread bits which are lib based. Again you
> can work around this stuff but it is much easier, and at no cost of
> functionality, to just use C++11 these days.
>
>
>
> On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <st...@stureynolds.com>
> wrote:
>
>> Just out of interest, what's the nature of Thrift's dependency on Boost?
>>
>> My recollection (also from embedded systems), is that *much* (but not
>> all) of Boost doesn't cause any real library dependencies because so
>> much of the Boost code is provided in full as template in header files
>> (i.e. it does not necessarily generate linker dependencies on boost
>> libraries).
>>
>> Is this the case for Thrift's use of boost? Does it require some
>> linking against a boost library -- and could that dependency be cut?
>>
>> - Stu
>>
>>
>>
>> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
>> <ra...@gmail.com> wrote:
>> > 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 <ro...@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 <hc...@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 <da...@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 <da...@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
>> >>>
>> >>
>> >>
>> >>
>>

Re: Thrift in an embedded setting

[Randy Abernethy <ra...@gmail.com>]

Most boost usage in Thrift is header based. The C++ lib "API" today uses
boost::shared_ptr liberally and there are lots of other small incursions.
While the elegance of Boost is uncontested, it is another dependency and as
far as the Thrift C++ lib is concerned, it is redundant in the context of
C++ >= 11. There are also boost thread bits which are lib based. Again you
can work around this stuff but it is much easier, and at no cost of
functionality, to just use C++11 these days.



On Mon, Jan 11, 2016 at 2:27 PM, Stuart Reynolds <st...@stureynolds.com>
wrote:

> Just out of interest, what's the nature of Thrift's dependency on Boost?
>
> My recollection (also from embedded systems), is that *much* (but not
> all) of Boost doesn't cause any real library dependencies because so
> much of the Boost code is provided in full as template in header files
> (i.e. it does not necessarily generate linker dependencies on boost
> libraries).
>
> Is this the case for Thrift's use of boost? Does it require some
> linking against a boost library -- and could that dependency be cut?
>
> - Stu
>
>
>
> On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
> <ra...@gmail.com> wrote:
> > 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 <ro...@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 <hc...@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 <da...@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 <da...@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
> >>>
> >>
> >>
> >>
>

Re: Thrift in an embedded setting

[Stuart Reynolds <st...@stureynolds.com>]

Just out of interest, what's the nature of Thrift's dependency on Boost?

My recollection (also from embedded systems), is that *much* (but not
all) of Boost doesn't cause any real library dependencies because so
much of the Boost code is provided in full as template in header files
(i.e. it does not necessarily generate linker dependencies on boost
libraries).

Is this the case for Thrift's use of boost? Does it require some
linking against a boost library -- and could that dependency be cut?

- Stu



On Mon, Jan 11, 2016 at 2:06 PM, Randy Abernethy
<ra...@gmail.com> wrote:
> 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 <ro...@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 <hc...@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 <da...@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 <da...@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
>>>
>>
>>
>>

Re: Thrift in an embedded setting

[Randy Abernethy <ra...@gmail.com>]

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 <ro...@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 <hc...@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 <da...@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 <da...@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
>>
>
>
>

Re: Thrift in an embedded setting

[Roger Meier <ro...@bufferoverflow.ch>]

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 <hc...@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 <da...@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 <da...@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

Re: Thrift in an embedded setting

[Konrad Grochowski <hc...@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 <da...@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 <da...@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

Re: Thrift in an embedded setting

[Randy Abernethy <ra...@gmail.com>]

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 <da...@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 <da...@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
> > > > >
> > > >
> > >
> >
>

Re: Thrift in an embedded setting

[Dane Mason <da...@gmail.com>]

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 <ra...@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 <da...@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
> > > >
> > >
> >
>

Re: Thrift in an embedded setting

[Randy Abernethy <ra...@gmail.com>]

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 <da...@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 <ra...@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
> > >
> >
>

Re: Thrift in an embedded setting

[Dane Mason <da...@gmail.com>]

Sorry I should have been more clear. C++ is fine, but the boost dependency
is problematic.

Dane

On Saturday, January 9, 2016, Randy Abernethy <ra...@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
> >
>

Re: Thrift in an embedded setting

[Randy Abernethy <ra...@gmail.com>]

Do you need a C impel or can you use C++11 on the embedded sys?

On Saturday, January 9, 2016, Dane Mason <da...@gmail.com> 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
>