thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 刘畅 <liuchang890...@hotmail.com>
Subject Re: Thrift in an embedded setting
Date Sun, 17 Jan 2016 02:58:14 GMT
I notice that U have merged the branch.

So, where exactly should we start?

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


Mime
View raw message